Un micro-outil par processus, pas un outil général
Un outil général reporte sur l'utilisateur la charge de la mise en contexte, refaite à l'identique à chaque usage. Une application dédiée capitalise ce contexte une fois — et c'est ce qui fait la différence entre un outil qui peut faire et un outil qui fait.
Sortir l'autorisation des applications
Tant que chaque application décide qui entre, chaque nouvelle application ajoute une décision de sécurité à maintenir. En concentrant cette décision dans un service unique, le coût marginal de sécurité d'une application supplémentaire devient proche de zéro : deux lignes au catalogue.
Rendre le lieu du calcul configurable
Aucune bibliothèque de fournisseur n'est embarquée : la plateforme parle un protocole HTTP, et chaque application y branche l'adresse, le modèle et la clé de son choix. Le lieu du calcul devient une décision d'exploitation, par application, et non une décision d'architecture.
Faire de la spécification un objet vivant
Chaque application a un cahier des charges versionné, alimenté par les retours des agents. Une proposition retenue devient une ligne de spécification, dans une version numérotée, avec le nom de son auteur.
Contexte & Problématique
Des processus qui ne sont pas décrits
L'obstacle n'est presque jamais la capacité de calcul : c'est qu'une démarche existe dans la tête de trois agents, dans un tableur, dans une habitude. Tant qu'elle n'est pas écrite, aucune assistance ne peut s'y greffer.
Un coût de sécurité payé à chaque outil
Si chaque application porte son identité, ses droits et sa trace, la dixième coûte autant que la première — et il n'y a jamais de dixième.
Une traçabilité qui n'existe qu'après coup
Savoir qui a accès à quoi, qui a utilisé quoi, et pouvoir retirer un accès immédiatement : ces trois capacités se conçoivent au départ ou ne s'obtiennent jamais.
Des retours utilisateurs sans chemin
Un signalement d'agent n'a pas de destination, pas de contexte, et ne débouche sur rien de visible. La vraie perte n'est pas dans les retours ignorés, mais dans ceux qui ne seront jamais formulés.
Réalisation
-
1. Le portail ouvre, il ne contient pas
La V1 chargeait les applications en modules JavaScript, la V2 injectait leurs fragments HTML : les deux exécutaient du code applicatif dans la page du portail. La V3 y renonce et redirige vers l'application, à sa propre adresse. Le cloisonnement devient celui du navigateur.
-
2. Un jeton dérivé, signé, court et nommé
Le jeton d'identité ne quitte plus le couple portail–Registry. Pour chaque application accessible, le Registry émet un jeton distinct signé en Ed25519, valable cinq minutes, portant l'application et le déploiement de destination, et révocable par introspection.
-
3. Un refus par défaut, assumé
Si le Registry est injoignable, l'application refuse l'accès plutôt que de l'accorder à l'aveugle. C'est un point de défaillance unique assumé — parce qu'une révocation qui n'est pas fiable ne sert à rien.
-
4. Deux canaux de traçabilité, pas un
Ce qui s'est passé dans le système et ce que les gens en ont fait sont deux questions distinctes : deux services, deux modèles de données, deux régimes de conservation, deux publics. Avec un sondeur de santé qui détecte les transitions en ligne / hors ligne.
-
5. Une boucle de contribution qui alimente la spécification
Un bouton présent dans chaque application, une destination unique, un tri par un administrateur, puis une réécriture assistée du cahier des charges — présentée avant enregistrement, jamais appliquée directement.
-
6. Une fabrique pour normaliser les suivantes
Un formulaire structuré produit le cahier des charges, les instructions de développement et l'arborescence d'une application de référence. Le passage par le Registry n'y est pas décochable, et aucun niveau de sécurité n'est coché par défaut.
Stack technique
Socle applicatif
Persistance
Identité et autorisation
Intégration des modèles
Observabilité
Interface
Distribution
Résultats & Impact
Une application qui tombe ne fait tomber qu'elle
Applications autonomes, bases séparées, cloisonnement par le navigateur : aucun style, aucun script d'une application ne peut atteindre une autre.
Le contrat d'intégration tient en trois obligations
Vérifier un jeton, émettre ses traces, renvoyer vers le portail. Une application n'a pas besoin de connaître le protocole d'identité pour rejoindre la plateforme.
La spécification cesse de vieillir
Le cahier des charges de chaque application est versionné et alimenté par les retours des agents — un actif qui vaut indépendamment de l'outil.
Une trace normalisée, donc opposable
Toutes les applications émettent le même objet, avec le même vocabulaire et au format ECS. C'est la condition d'une politique de preuve : l'horodatage qualifié et le stockage en écriture unique se posent ensuite, sur une matière déjà cohérente.
Une feuille de route de durcissement écrite
Trois chantiers circonscrits et sans refonte : jetons de service pour le canal d'ingestion, état de révocation sorti du processus, droit à l'oubli étendu aux journaux. Nommés avant la mise en service — donc planifiables.
Galerie
