Une plateforme d'interconnexion n'a pas besoin de stocker vos données
Empreintes, compteurs et clés en échec suffisent à piloter des flux. Les contenus transitent sans être conservés, et l'état de comparaison reste chez le bailleur.
Quand une DSI de bailleur social examine une plateforme d’interconnexion, la première question n’est jamais fonctionnelle. Elle est : où vont nos données, et qui peut les lire ?
La réponse la plus confortable serait « elles sont chiffrées ». Ce n’est pas la nôtre. La nôtre est : elles ne sont pas conservées.
Ce qu’une plateforme croit avoir besoin de stocker
Un service d’interconnexion classique construit une base centrale. L’argument est solide en apparence : pour savoir ce qui a changé, il faut connaître l’état précédent ; pour rejouer un envoi, il faut avoir gardé le message ; pour diagnostiquer, il faut pouvoir relire.
Le résultat, c’est un entrepôt de données personnelles hébergé chez un tiers, qui concentre les informations de tous les organismes clients. Un objet qui n’existait pas avant le projet, et qui devient immédiatement la cible la plus intéressante du système d’information.
Trois choix qui rendent ce stockage inutile
L’état de comparaison reste chez vous. C’est l’agent installé sur votre réseau qui garde la trace de ce qu’il a déjà vu, dans une base locale. C’est lui qui compare et qui décide ce qui a changé. Le plan de contrôle central n’a jamais besoin de connaître l’état de votre patrimoine : il reçoit un écart déjà calculé.
Le central ne conserve que des empreintes. Une empreinte est une signature technique calculée sur un contenu. Elle permet de savoir que deux versions diffèrent, de vérifier qu’un message est arrivé intact, de détecter un rejeu, sans jamais permettre de reconstituer le contenu. Une empreinte de nom de locataire n’est pas un nom de locataire.
Les contenus transitent avec une rétention nulle. Un message passe par le plan de contrôle pour être traduit et acheminé. Il est traité, il part, il n’est pas écrit sur disque. Ce qui reste après coup : un compteur, un horodatage, et, en cas d’échec, une clé technique permettant de rejouer la demande à la source.
Ce que le central garde vraiment
Trois choses, et c’est tout :
- des empreintes, pour vérifier et détecter les écarts ;
- des compteurs et des horodatages, pour superviser et alerter ;
- des clés en échec, pour savoir quoi redemander à l’agent quand un envoi n’est pas passé.
Une clé en échec est un identifiant technique, pas un contenu. Elle permet de dire à l’agent : « l’objet numéro tel n’est pas passé, renvoie-le ». L’agent, lui, a le contenu, parce qu’il est chez vous.
La conséquence la plus utile : les journaux
Cette contrainte a un corollaire qu’on sous-estime toujours : aucun journal, aucun message d’erreur ne doit pouvoir contenir une valeur de ligne.
C’est là que la plupart des architectures par ailleurs correctes se trahissent. L’application ne stocke rien, mais quand un envoi échoue, la trace d’erreur recopie fidèlement l’objet fautif, avec le nom, l’adresse et le numéro de contrat. Et cette trace part dans un outil de supervision, elle est conservée trente jours, elle est lisible par l’astreinte.
Une plateforme qui prend cette contrainte au sérieux la traite comme un critère de recette, pas comme une bonne intention. Chez nous, un message d’erreur qui laisserait fuiter une valeur de ligne est un défaut bloquant, au même titre qu’un test rouge.
Ce que ça change pour vous
L’analyse d’impact est courte. Il n’y a pas de traitement de données personnelles à documenter du côté du plan de contrôle, parce qu’il n’y a pas de conservation.
Le périmètre d’un incident est borné. Une compromission du central donnerait accès à des empreintes et à des compteurs. C’est ennuyeux ; ce n’est pas votre fichier locataires.
La réversibilité est réelle. Vous arrêtez la plateforme : rien à récupérer, rien à faire effacer chez nous. Vos données n’ont jamais quitté votre périmètre autrement qu’en transit.
L’objection honnête
Cette architecture coûte quelque chose. Le diagnostic est plus difficile : quand un envoi se passe mal, on ne peut pas relire le message fautif dans une base centrale, il faut aller le chercher chez le client. Nous assumons ce coût, parce qu’il pèse sur nous et que l’alternative pèserait sur vous.
Une exigence de sécurité qui ne coûte rien à celui qui la promet n’a en général pas beaucoup de valeur.
Vous voulez en parler pour votre organisme ? Écrivez-nous à contact@oxli.io ou demandez une démonstration.