L'architecture produit doit séparer ce que l'équipe cherche à accomplir, ce qu'elle peut faire et la manière dont l'organisation contrôle le résultat.
En bref
Un Operating Layer est la couche de travail qui relie une mission métier aux rôles, au contexte, aux outils et aux contrôles. Avant un déploiement, exigez six capacités distinctes : identité, mandat, contexte, orchestration, accès outillé et preuve. Si une seule de ces capacités reste implicite, le système devient difficile à gouverner et à améliorer.
Ce cadre est une grille d'architecture éditoriale. Il ne constitue pas une liste contractuelle de fonctionnalités Atlensia.
Les six capacités à distinguer
| Capacité | Question produit | Objet à vérifier |
|---|---|---|
| Identité | Qui agit et pour quelle fonction ? | Identité dédiée, rôle, propriétaire humain |
| Mandat | Quel résultat est attendu ? | Objectif, critères de sortie, cas exclus |
| Contexte | Quelles informations sont pertinentes maintenant ? | Sources autorisées, fraîcheur, provenance, mémoire de travail |
| Orchestration | Comment le travail passe-t-il d'un rôle à l'autre ? | État, priorités, handoffs, reprise après erreur |
| Accès outillé | Quelles actions sont permises ? | Permissions minimales, limites, idempotence, révocation |
| Preuve | Comment comprendre le résultat ? | Traces, validations, métriques, versions de règles |
La plateforme Atlensia présente les équipes autonomes comme des rôles coordonnés, intégrés aux outils et encadrés par des règles. Cette lecture place l'architecture de travail avant le choix du modèle.
Une architecture en trois plans
Le plan de décision contient le mandat, les priorités et les règles. Le plan d'orchestration gère l'état du travail, les rôles et les transmissions. Le plan d'exécution appelle les outils et les données. Les contrôles traversent les trois plans : identité, permission, validation, journal, limite de coût et arrêt.
Cette séparation rend les changements localisables. Remplacer un modèle ne devrait pas redéfinir les droits. Ajouter un connecteur ne devrait pas modifier le mandat. Changer une règle de validation ne devrait pas effacer l'historique des décisions.
Gérer le contexte comme une ressource
Le contexte utile n'est pas l'accumulation de tous les documents disponibles. C'est un ensemble borné de faits, règles et objets métier nécessaires à la tâche. Chaque élément devrait avoir une source, une date, un propriétaire et une durée de validité.
Trois compartiments réduisent les erreurs :
- Le contexte de référence contient les règles stables et versions approuvées.
- Le contexte de dossier contient les informations propres au cas traité.
- La mémoire de travail contient les étapes temporaires, hypothèses et résultats intermédiaires.
Une hypothèse ne doit jamais être promue silencieusement en donnée de référence. Le passage entre compartiments exige une règle ou une validation.
Concevoir les handoffs comme des contrats
Un handoff n'est pas un simple message entre deux agents. Il doit préciser l'objet transmis, l'état atteint, les contrôles déjà réalisés, les éléments manquants, la prochaine responsabilité et la condition d'escalade.
| Champ du handoff | Exemple |
|---|---|
| Objet | Dossier fournisseur 2026-184 |
| État | Pièces vérifiées, montant extrait |
| Preuves | Contrat, facture, référentiel fournisseur |
| Incertitude | Centre de coût absent |
| Prochaine responsabilité | Contrôle finance |
| Escalade | Responsable achats si montant supérieur au seuil |
Cette structure permet une reprise après incident et évite qu'un rôle hérite d'une conclusion sans savoir comment elle a été obtenue.
Découpler modèles et politiques
Les modèles évoluent, mais les politiques d'entreprise doivent rester lisibles et testables. Les droits d'accès, seuils d'approbation, règles de conservation et limites de coût ne devraient pas vivre uniquement dans une consigne adressée au modèle.
Le NIST AI Risk Management Framework fournit une structure utile pour relier gouvernance, cartographie des impacts, mesure et traitement. Côté autorisation, le RFC 9700 consolide les bonnes pratiques de sécurité OAuth 2.0. Ces sources convergent vers une même exigence : séparer la décision de politique de l'exécution technique.
Tester les modes dégradés
Une architecture produit se juge aussi lorsque quelque chose manque. Testez au minimum : source indisponible, donnée contradictoire, connecteur lent, limite d'API atteinte, modèle indisponible, validation sans réponse et révocation d'un accès pendant une tâche.
Pour chaque cas, le système doit choisir explicitement entre reprendre, attendre, escalader ou arrêter. Continuer avec un contexte incomplet ne doit pas être le comportement par défaut.
Grille de sélection avant déploiement
Demandez une démonstration vérifiable de ces six points :
- une identité et un propriétaire humain par rôle ;
- un mandat versionné avec cas exclus ;
- une provenance visible pour le contexte critique ;
- un handoff reconstructible entre deux rôles ;
- une permission révocable sans interrompre toute la plateforme ;
- une trace reliant entrée, règle, action, validation et sortie.
Ajoutez ensuite les exigences propres au métier : résidence des données, chiffrement, reprise, coût, latence, intégration et conservation.
Conclusion
Le bon Operating Layer ne cherche pas à masquer la complexité opérationnelle. Il la rend explicite, attribuable et testable. Commencez par dessiner les trois plans et les six capacités sur un workflow réel. Toute case sans propriétaire, preuve ou règle devient une exigence de conception avant le déploiement.