À retenir - Sécurisation des données
- La majorité des fuites de données viennent d'oublis dans la couche applicative chargée des droits, et non d'attaques sophistiquées.
- Optim-SI embarque le contrôle d'accès (GBAC) directement dans le moteur de données : aucun accès ne peut physiquement contourner les règles.
- Le GBAC graphe permet d'exprimer des droits contextuels et transitifs (hiérarchies, délégations, portefeuilles…) impossibles à modéliser proprement en SQL.
- Modifier une politique de sécurité ne nécessite aucun déploiement applicatif — c'est une opération sur les données du graphe.
La sécurité comme propriété émergente… ou structurelle
La grande majorité des incidents de sécurité impliquant des fuites de données d’entreprise ne résultent pas d’une attaque sophistiquée sur l’infrastructure. Ils proviennent d’une erreur de développement — un endpoint d’API insuffisamment protégé, un filtre de droits oublié dans une nouvelle fonctionnalité, une requête SQL trop large dont les résultats n’ont pas été filtrés avant exposition.
La sécurité, dans ces systèmes, est une propriété émergente du code applicatif : elle n’est garantie que si chaque développeur, à chaque évolution, applique correctement une série de conventions. Elle repose sur la vigilance humaine.
Optim-SI prend le parti inverse. Sa sécurité est une propriété structurelle du moteur de données : les règles d’accès sont embarquées dans la base elle-même et appliquées par le moteur avant toute restitution de donnée. Il est physiquement impossible pour une couche applicative de restituer une donnée que le moteur juge non accessible.
Panorama des architectures de sécurité les plus répandues
La surcouche applicative (le cas le plus fréquent)
C’est l’architecture dominante dans les applications web d’entreprise : une base de données relationnelle classique (PostgreSQL, SQL Server, Oracle…) sans politique de droits native, exposée via une couche applicative qui est seule responsable du filtrage des accès.
La sécurité au niveau base de données (Row-Level Security)
Des SGBD comme PostgreSQL (RLS), Oracle (VPD) ou SQL Server proposent un mécanisme de filtrage des lignes activé par des politiques SQL associées au contexte de session. C’est une avancée significative : le filtrage est dans le moteur.
Limite : ces mécanismes restent fondamentalement tabulaires et statiques. Modéliser des droits qui dépendent de la position d’un objet dans une hiérarchie organisationnelle, d’une relation transitive ou d’une délégation temporaire nécessite des jointures complexes dans les politiques — ce qui devient vite ingérable.
Les IAM et gestionnaires de politiques externes (RBAC / ABAC)
Des solutions comme AWS IAM, Azure RBAC, ou des frameworks ABAC (Open Policy Agent…) centralisent les règles dans un service dédié consulté à chaque décision. 
Limite : l’indirection. Le moteur de politique raisonne sur des attributs déclarés par l’application, pas sur les données elles-mêmes. Les règles contextuelles complexes nécessitent de pré-calculer et synchroniser des attributs, créant une source supplémentaire d’inconsistance.
Les bases de données graphes avec sécurité native
Les bases de données graphes (Neo4j, Amazon Neptune…) offrent une modélisation naturelle des relations et hiérarchies.
Limite : le contrôle d’accès reste généralement au niveau du label de nœud ou de la relation — granularité grossière — et la logique métier contextuelle doit souvent être ré-implémentée en dehors du moteur.
Le GBAC embarqué d'Optim-SI : la sécurité comme propriété du moteur
Architecture générale
Optim-SI stocke l’ensemble des données d’entreprise — applications, projets, budgets, contrats, acteurs, organisations — sous forme d’un réseau de nœuds typés et liés. Ce modèle graphe est natif : il n’y a pas de schéma relationnel sous-jacent.
La distinction fondamentale : le filtre ne se situe pas entre l’API et la base, mais à l’intérieur du moteur de traversée. Quand Optim-SI résout une requête, il ne récupère jamais des nœuds non autorisés pour les filtrer ensuite — il ne les traverse simplement pas.
Cette règle est déclarative, centralisée, et évaluée par le moteur à chaque traversée. Elle couvre automatiquement tous les accès — API REST, export, reporting, intégration Power BI via OData, API MCP, tout futur point d’accès.
Les quatre garanties structurelles
| Exhaustivité irréfragable | Aucun chemin de code ne permet de contourner l’évaluation GBAC. Un développeur ne peut pas « oublier » d’appeler la vérification : elle est intégrée dans l’acte même de lire un nœud. |
| Cohérence permanente | Il ne peut exister de contradiction entre ce que l’interface affiche et ce qu’un export révèle. La politique de sécurité est une, quelle que soit la fonctionnalité qui accède aux données.. |
| Performance intrinsèque | Le moteur ne charge en mémoire que les nœuds accessibles. Pour un périmètre restreint dans un graphe de nœuds, la traversée est immédiatement contrainte. |
| Évolutivité sans déploiement | Modifier une politique de sécurité consiste à modifier des règles dans le graphe — une opération de données, pas de code. Aucun déploiement applicatif n’est requis |
Implications concrètes pour la gouvernance IT
Pour les DSI et RSSI, cette architecture a des conséquences directes sur la posture de sécurité de l’organisation.
| Réduction de la surface d’attaque | Une injection SQL, une manipulation de paramètre d’API, ou un accès direct à la base via des credentials compromis ne permettent pas d’extraire de données non autorisées : le moteur refuse la traversée des nœuds concernés. |
| Conformité réglementaire simplifiée | Démontrer à un auditeur (RGPD, ISO 27001, SOC 2) que les données du client A ne sont jamais accessibles au client B est une affirmation formellement vérifiable en interrogeant les règles GBAC — et non une promesse sur la qualité du code. |
| Résilience aux erreurs de développement | Dans un cycle de développement actif, chaque nouvelle fonctionnalité est automatiquement couverte par le GBAC existant, sans qu’aucune action de sécurité supplémentaire ne soit requise de la part du développeur. |
Conclusion
La sécurité des données d’entreprise ne peut pas être réduite à une convention de développement ou à la vigilance de chaque développeur sur chaque fonctionnalité. L’histoire des incidents démontre que cette approche échoue systématiquement à l’échelle et dans la durée.
Optim-SI a fait le choix architectural de traiter la sécurité comme une propriété du moteur de données lui-même. Le mécanisme GBAC embarqué garantit structurellement — et non conventionnellement — qu’aucune donnée ne peut être restituée à un acteur non autorisé, quelle que soit la voie d’accès, quelle que soit l’évolution du code applicatif.
C’est cette différence de nature, et non de degré, qui distingue une plateforme à sécurité intrinsèque d’une application sécurisée.
