Toutes les données ne se valent pas. Un article de blog peut être public. Une liste de produits peut être mise en cache sur un CDN mondial. Mais un dossier client, des informations financières, des données personnelles sensibles — ces données appellent une architecture radicalement différente.
La question n’est pas seulement technique. Elle est juridique et potentiellement pénale. Voici ce que votre outil numérique doit garantir — et pourquoi le choix de l’architecture n’est pas un détail.
Le cadre réglementaire : une obligation, pas une option
Le RGPD impose à tout responsable de traitement des obligations claires : minimisation des données collectées, sécurisation des accès, droit à l’effacement, notification en cas de fuite.
Ces obligations s’appliquent quelle que soit la taille de votre structure. Un cabinet de quelques personnes qui gère des dossiers clients est soumis aux mêmes principes fondamentaux qu’un groupe de plusieurs centaines de salariés.
Ce qui change selon les secteurs, c’est le niveau de sensibilité des données et les référentiels sectoriels qui s’y ajoutent. Mais dans tous les cas, la responsabilité en cas d’incident repose sur le responsable de traitement — pas sur l’éditeur du logiciel qu’il a choisi d’utiliser.
Ce que l’architecture doit garantir concrètement
Le cloisonnement des données. Chaque client, chaque dossier doit être isolé. Un bug d’autorisation dans un logiciel multi-tenant peut exposer les données d’un client à un autre. Sur un logiciel sur mesure, cette isolation est conçue dès le départ — pas ajoutée en option.
Le chiffrement au repos et en transit. Les données sensibles ne circulent jamais en clair, ni sur le réseau ni dans les bases de données. TLS pour les échanges, AES-256 pour le stockage. Ce n’est pas une configuration optionnelle — c’est une exigence de base pour toute donnée à caractère personnel.
La gestion des droits par rôle (RBAC). Chaque profil utilisateur accède uniquement à ce qui le concerne. L’architecture doit imposer ces cloisonnements structurellement, pas par convention ou bonne volonté.
La traçabilité des accès. En cas d’incident ou de contrôle, vous devez pouvoir répondre à la question : qui a accédé à quoi, quand, depuis où ? Un journal d’audit complet et inaltérable est indispensable dès que des données sensibles sont en jeu.
La souveraineté de l’hébergement. Un hébergement en France ou dans l’UE réduit l’exposition au Cloud Act américain et aux transferts hors Espace Économique Européen. Pour certains secteurs, c’est une obligation. Pour tous, c’est une précaution légitime.
Pourquoi un logiciel sur mesure change la donne
Un SaaS généraliste est conçu pour le marché le plus large possible. Ses compromis d’architecture reflètent les besoins moyens de milliers de clients différents — pas les exigences spécifiques de votre contexte.
Un logiciel sur mesure est architecturé pour votre réalité précise : votre niveau de sensibilité des données, vos obligations réglementaires, vos flux internes. Le code vous appartient — vous savez exactement ce qu’il fait, où vont vos données, et qui y a accès.
Confier des données sensibles à un outil dont vous ne maîtrisez pas l’architecture, c’est déléguer une responsabilité que la réglementation ne vous permet pas de déléguer.
La protection des données sensibles ne commence pas par une politique de confidentialité. Elle commence par l’architecture.
