Aller au contenu
/01Gouvernance6 min

Juste sur le goulot d'étranglement. La porte doit passer à l'échelle.

Le playbook du SDLC natif de l'IA d'Anthropic automatise déjà l'essentiel du travail entre les décisions. Reste à y ajouter une couche d'arbitrage qui décide, à chaque transition, ce que la preuve autorise.

Anthropic publie l’exposé le plus clair à ce jour du cycle de vie de développement logiciel natif de l’IA. Il décrit déjà des passages de relais automatisés, la revue agentique et une boucle opérationnelle fermée. L’étape qui reste est plus étroite, mais lourde de conséquences : appliquer une délégation explicite, pilotée par la politique, à chaque transition.

Le diagnostic est juste

Le playbook du SDLC natif de l’IA d’Anthropic s’ouvre sur le diagnostic que nous aurions choisi : le code n’est plus le goulot d’étranglement.

Quand des agents compriment l’implémentation de plusieurs semaines à quelques heures, la planification, la conception, la revue, la sécurité et la mise en production ne disparaissent pas. Si ces activités continuent à vitesse humaine pour chaque modification, la file d’attente ne fait que se déplacer.

Anthropic remplace les passages de relais linéaires par une chaîne d’artefacts versionnés : intention, spécification, plan, code, tests, constats et enregistrements d’incident. Les artefacts acceptés déclenchent les étapes suivantes. Les skills portent la connaissance institutionnelle, les hooks imposent des frontières d’action et les revues agentiques réduisent ce que les personnes doivent inspecter directement.

C’est déjà plus qu’une collection de prompts. C’est un modèle de cycle de vie, avec de l’automatisation sur six étapes.

La question laissée ouverte n’est pas de savoir si le cycle de vie doit devenir une boucle. Anthropic y a répondu.

La question est de savoir ce qui décide qu’un travail a le droit d’y avancer.

Automatiser n’est pas déléguer

Le playbook automatise une grande part du travail entre les décisions, mais plusieurs transitions exigent encore qu’une personne approuve chaque modification.

Un product owner accepte l’intention et relit la spécification. Des ingénieurs acceptent le plan. Un propriétaire de code approuve la pull request. Des autorités nommées approuvent les mises en production lourdes de conséquences.

Ces points de contrôle sont appropriés quand du jugement est requis. Ils deviennent un goulot d’étranglement quand un travail de routine et conforme emprunte le même circuit.

Skills, hooks, revues agentiques et protection de branche résolvent chacun une partie du problème. Ils ne forment pas, à eux seuls, une couche de décision unique qui évalue chaque transition au regard de la politique de délégation de l’organisation.

Sans cette couche, davantage de production agentique produit toujours davantage de matière à approuver pour des personnes.

La boucle de maintenance montre le schéma le plus solide

Le modèle de délégation le plus complet du playbook apparaît dans son étape Maintain.

Un script déterministe observe les métriques de production. Des seuils versionnés déterminent qu’une condition a été franchie. Le modèle n’est invoqué qu’à ce moment-là. Un palier de réponse contraint ce qu’il peut faire : enregistrer l’événement, enquêter sans rien modifier, ouvrir une pull request ou déclencher un runbook pré-approuvé.

Le schéma est solide :

  1. L’organisation définit la condition.
  2. Un mécanisme déterministe produit la preuve.
  3. Une politique versionnée détermine la réponse permise.
  4. L’agent agit à l’intérieur de permissions bornées.
  5. Une personne reçoit les exceptions et les décisions lourdes de conséquences.
  6. Chaque entrée, verdict et action reste reconstituable.

Anthropic introduit également une porte de confiance indépendante lorsque cette boucle de maintenance autonome fait passer du travail aux étapes suivantes.

Les composants existent donc déjà. L’étape suivante consiste à faire de cette délégation pilotée par la politique le modèle opératoire de chaque transition du cycle de vie.

Chaque transition a besoin d’un arbitre

Un cycle de vie natif de l’IA a besoin d’agents qui produisent le travail et de contrôles qui l’inspectent. Il a aussi besoin d’une couche d’arbitrage qui décide ce que la preuve autorise.

De l’intention à la conception, le système doit établir si les contraintes obligatoires, la propriété et les questions ouvertes ont été traitées.

De la conception au build, il doit évaluer les frontières architecturales, les dépendances approuvées, les exigences de sécurité et les exceptions non résolues.

Du build au test, il doit déterminer si l’implémentation correspond à la conception acceptée et si la preuve requise existe.

Du test à la mise en production, il doit combiner les résultats de tests, les constats de sécurité, la classification de la modification et la politique de déploiement.

À chaque porte, l’issue doit être explicite : avancer, réparer, arrêter ou escalader.

Cette issue ne peut pas reposer sur la seule confiance du modèle. Les modèles savent évaluer un contexte et produire des constats, mais l’autorité doit venir d’une politique approuvée. Les conditions objectives doivent être testées de façon déterministe. Les évaluations contextuelles doivent être bornées, consignées et ouvertes à une contestation indépendante.

Les agents produisent le travail. Les contrôles produisent la preuve. La politique arbitre. Les personnes possèdent les règles et décident des exceptions.

C’est cela, déléguer.

L’autorité humaine n’est pas le débit humain

Responsabilité humaine et intervention humaine ne sont pas synonymes.

Les autorités d’architecture peuvent approuver les frontières que chaque système doit respecter. La sécurité peut définir quels constats bloquent, lesquels peuvent être réparés automatiquement et lesquels exigent une revue. Les autorités de mise en production peuvent établir les conditions dans lesquelles un déploiement peut avancer.

Ces personnes restent responsables parce qu’elles possèdent la politique et conservent l’autorité sur les exceptions. Elles n’ont pas besoin d’inspecter individuellement chaque sortie conforme.

C’est ainsi que toute grande organisation passe à l’échelle. Les dirigeants définissent les mandats, les droits de décision et les règles d’escalade. Les équipes opèrent à l’intérieur de ces frontières. Seules les exceptions et les décisions lourdes de conséquences remontent la hiérarchie.

La production logicielle agentique exige le même modèle opératoire, rendu exécutable et auditable.

Conseil, évaluation et arbitrage sont trois choses différentes

Anthropic distingue skills et hooks. Les skills conseillent le modèle. Les hooks imposent des frontières déterministes autour de ses actions.

Une usine gouvernée a besoin d’une troisième catégorie.

Le conseil dit à l’agent comment il devrait se comporter.

L’évaluation détermine ce qu’il a produit et si les exigences observables ont été satisfaites.

L’arbitrage applique la politique de l’organisation à cette preuve et décide de ce qui peut arriver ensuite.

Un prompt ne peut pas certifier que son instruction a été suivie. Un modèle qui rapporte sa conformité ne constitue pas une preuve indépendante. Un hook peut bloquer une action précise, mais un ensemble de hooks locaux ne devient pas automatiquement une politique de cycle de vie cohérente.

Cela compte tout particulièrement pour l’architecture. La documentation, les skills et les consignes de revue peuvent guider la génération, mais elles ne rendent pas l’architecture mesurable.

Les patterns approuvés, le sens des dépendances, les règles d’interface, les frontières de propriété et les invariants structurels ont besoin de représentations applicables. Les règles qui guident la génération doivent aussi produire les contrôles qui jugent le résultat.

Mesurer la porte, pas seulement le flux

Le temps de revue, le taux d’acceptation et la fréquence de déploiement décrivent le flux. Ils n’établissent pas qu’une porte a pris la bonne décision.

Un taux d’acceptation qui monte peut signifier que la génération s’est améliorée. Il peut aussi signifier que le contrôle est devenu permissif.

Un système de production gouverné doit donc mesurer à la fois la vélocité et la qualité du contrôle : faux positifs, faux négatifs, dérogations, échappées et coût d’un résultat de production réussi.

Le juge doit être mesurable lui aussi. Sinon, un verdict automatisé n’est pas plus falsifiable qu’un refus humain inexpliqué.

Ce que nous gardons et ce que nous étendons

Nous gardons la chaîne d’artefacts versionnés d’Anthropic, les passages de relais automatisés, les plans explicites, la séparation entre écriture et approbation, l’évaluation continue, la revue agentique et les paliers de réponse versionnés.

Nous étendons ce schéma de contrôle à l’ensemble du cycle de vie.

Chez Solario, c’est déjà le modèle opératoire.

Le harnais de gouvernance Solario lie chaque Projet avant l’exécution et reste actif de l’Intention signée jusqu’au déploiement. La politique d’Usine et de Projet définit l’architecture, les stacks approuvées, les ADR, les standards de qualité, les obligations de test et les exceptions autorisées avant que les agents ne commencent à travailler.

Solario Core possède la machine à états et chaque transition légale du cycle de vie. Les agents y exécutent un travail borné. Ils ne définissent pas les règles et n’autorisent pas leur propre progression.

À chaque porte, des contrôles déterministes vérifient les artefacts et les résultats déclarés. La politique détermine si le Workload avance, entre en boucle de réparation, s’arrête ou atteint une autorité humaine nommée. L’approbation humaine est réservée aux moments où le jugement ne peut pas être délégué.

Chaque verdict est conservé avec ses entrées, ses contrôles, ses constats, ses réparations, ses exceptions et ses approbations. Le dossier de production se crée avec le logiciel au lieu d’être reconstitué après coup.

L’accès aux modèles passe par un SDK contrôlé qui prend en charge les points d’accès frontières et à poids ouverts. Les modèles restent des ressources de production remplaçables. Les politiques, les portes et l’historique des décisions de l’organisation ne changent pas quand le fournisseur change.

C’est là toute la différence entre ajouter des agents à un processus de livraison et opérer une usine logicielle IA gouvernée.

Anthropic a raison sur le goulot d’étranglement. Il a aussi raison sur la forme de la boucle.

La porte doit désormais opérer à la même échelle.

Solario le fait déjà.

Solario · Point of View /01

← Tous les articles