Identix : plateforme de gestion des identités et des accès

Identix est un fournisseur d’identité auto-hébergé. Une entreprise l’installe dans sa propre infrastructure, et une seule installation dessert de nombreuses applications indépendantes (locataires), chacune avec ses propres utilisateurs, rôles, paramètres de connexion et clés de signature. Mots de passe, clés et données personnelles ne quittent jamais l’infrastructure de l’exploitant.

L’identité est la partie la plus sensible de tout système sur le plan de la sécurité : une erreur à ce niveau expose toutes les applications qui en dépendent. Le projet devait donc associer une fonctionnalité étendue à une architecture de sécurité capable de résister à un examen rigoureux. Il a été conçu et développé, et il est maintenu, par un seul ingénieur.

Serveur d’autorisation — OAuth 2.0 et OpenID Connect sur Spring Authorization Server, avec un émetteur et des clés de signature distincts pour chaque locataire, la rotation des jetons d’actualisation et la révocation immédiate des jetons.

• Cloisonnement strict des locataires — chaque requête reste confinée à son locataire, et des tests d’architecture automatisés font respecter cette règle
• Utilisateurs, rôles, groupes et organisations, avec import et export en masse et une politique de mots de passe propre à chaque locataire
• Authentification à deux facteurs (TOTP) avec codes de récupération
• Emprunt d’identité journalisé — un administrateur peut agir au nom d’un utilisateur, et chaque session de ce type est enregistrée
• Webhooks signés par HMAC pour les événements du cycle de vie des utilisateurs
• Journal d’audit — propre à chaque locataire, les entrées ne pouvant qu’y être ajoutées, avec une vue transversale pour l’exploitant
• Export et import de la configuration des locataires entre installations

Console d’administration — React et TypeScript, en anglais et en russe, adaptée de l’ordinateur au téléphone, avec un espace développeurs intégré : guides d’intégration et documentation interactive de l’API.

API publique — 237 opérations, entièrement décrites en OpenAPI.

Infrastructure — trois services sur Kubernetes avec des charts Helm, PostgreSQL et Redis, ainsi que trois chaînes CI/CD GitLab qui compilent, testent et déploient chaque service. Le déploiement est bloqué si un seul test échoue.

L’architecture sépare les zones de confiance. Le serveur d’autorisation public n’a pas accès à la base de données et ne détient aucune clé privée : toutes les données et la signature de tous les jetons relèvent d’un service interne, accessible uniquement à l’intérieur du cluster. Les clés de signature sont stockées chiffrées et ne sont déchiffrées qu’en mémoire ; la compromission du nœud public n’expose donc ni les clés ni les données.

La sécurité faisait partie de la méthode ; elle n’a pas été ajoutée après coup :

• Modèle de menaces établi selon STRIDE : actifs protégés, profils d’attaquants, frontières de confiance et une contre-mesure pour chaque menace
• Documentation de sécurité destinée aux auditeurs, avec des mesures de sécurité mises en correspondance avec OWASP ASVS niveau 2 et les bonnes pratiques de l’IETF pour OAuth 2.0 et JWT
• Audit de sécurité mené à bien ; toutes les constatations ont été corrigées

Un seul ingénieur, à la fois architecte et orchestrateur des agents d’IA, travaillant selon le Specification-Driven Development. Le travail a commencé par une spécification écrite (exigences, modèle de données, invariants de sécurité), et chaque décision importante a été consignée dans un dossier de décision d’architecture (ADR) avant l’implémentation.

Les agents d’IA ont produit le code, les tests et la documentation à partir de cette spécification ; l’ingénieur examinait chaque modification, était responsable de l’architecture et du modèle de sécurité et répondait de chaque commit. L’infrastructure (manifestes Kubernetes, charts Helm, chaînes CI/CD) a été construite par la même personne, de la même manière.

Le développement n’a pas été continu : le projet a progressé par étapes, entrecoupées de pauses. En ne comptant que les jours effectivement travaillés, la plateforme a demandé 40 jours de travail.

La gestion des identités et des accès n’est pas une vitrine évidente pour une livraison rapide : elle associe un large éventail de fonctionnalités à des exigences de sécurité sans concession. Identix montre que la méthode tient aussi dans ce domaine.

Un ingénieur. 40 jours de travail. Un serveur d’autorisation multilocataire, une console d’administration, une API publique de 237 opérations, environ 1 700 tests automatisés, Kubernetes et CI/CD, ainsi qu’une architecture de sécurité étayée par un modèle de menaces et un audit mené à bien.

Le facteur décisif n’a pas été la vitesse de génération du code, mais la discipline qui l’encadre : la spécification d’abord, les décisions consignées, chaque modification examinée. C’est ce qui rend le système maintenable, et ce qui permettrait à une autre équipe d’en reprendre la charge.