Daniel Meppiel, qui dirige le go-to-market de l'Agentic SDLC chez Microsoft et a écrit The Agentic SDLC Handbook, a publié une proposition pour permettre aux entreprises de faire confiance au code produit par des agents d'IA sans en relire chaque ligne. Avant Microsoft, il a travaillé sur les systèmes distribués au CERN, puis sur les outils de développement chez GitHub et Sonar. L'essai, intitulé "Agent Contracts and Receipts: toward verifiable agentic software factories", est paru le 4 novembre 2026 sur son site, The AI Native Mind. Il prolonge son intervention à l'aiDevCon NYC, "Version your factory, not just your code", et s'accompagne d'une spécification sur GitHub que l'auteur présente comme une version de travail 0.1, "une invitation, pas une norme".

Meppiel part d'un goulet d'étranglement que les grandes entreprises rencontrent selon lui sans cesse. Les agents de programmation ont rendu la production de modifications peu coûteuse, mais chaque pull request attend toujours que l'intégration continue relance tous les tests et qu'un humain la relise. Les classificateurs de risque qui fusionnent seuls les petits changements aident, reconnaît-il, mais toucher à la validation des paiements n'est jamais anodin, et un classificateur ne juge que la modification elle-même, pas le système qui l'a écrite ni son autorisation par l'entreprise. Sa thèse : la confiance ne peut venir ni du modèle ni de la lecture de ce qu'il produit, elle doit venir du système de production, conçu et attesté comme n'importe quelle chaîne d'approvisionnement logicielle.

L'élément central est l'Agent Contract, un fichier unique et versionné qui décrit une tâche confiée à un agent, à la manière d'une fiche de poste pour une nouvelle recrue. Il précise les fichiers dont il a besoin et ceux qu'il livre, importe des compétences (skills) aux versions figées, fixe un budget de tentatives et de secondes, et énumère les vérifications qui jugeront le résultat, arrêtées avant l'exécution. Les contrats s'enchaînent en un graphe que Meppiel appelle usine logicielle agentique, et l'ensemble reçoit une seule version et une empreinte, un condensat qui couvre chaque contrat, chaque vérification et chaque compétence. L'usine ne désigne aucun agent particulier ; elle tourne aujourd'hui sur GitHub Copilot CLI ou OpenCode.

Chaque exécution terminée laisse un reçu, un paquet in-toto portant sur les fichiers exacts livrés. On y trouve une provenance SLSA indiquant la version de l'usine, les étapes, l'agent, le modèle et le commit de départ ; un résultat de test in-toto pour chaque vérification déclarée ; et un ABOM, une nomenclature de l'agent au format CycloneDX qui recense les compétences et paquets fournis, chacun figé par son empreinte de contenu. Selon l'auteur, le modèle habituel de la chaîne d'approvisionnement doit évoluer sur deux points. Le travail d'un agent ne se reconstruit pas à l'identique, donc une tâche distincte, sans agent ni jeton de modèle, rejoue les vérifications sur les fichiers livrés. Et comme l'agent est l'acteur le moins fiable, il ne signe jamais : un workflow de CI figé, hors de sa portée, valide le reçu et le signe avec Sigstore.

Dernière pièce : un contrôle obligatoire unique au moment du merge. Un fichier de politique géré par l'équipe sécurité, apm-policy.yml, liste les empreintes des usines approuvées, le signataire de confiance, les sources de compétences autorisées et les compétences révoquées ; chaque dépôt peut durcir les règles de l'organisation, jamais les assouplir. Le contrôle lit la politique sur la branche de base, recherche chaque fichier modifié par son condensat SHA-256 dans le magasin d'attestations du signataire et rejette tout ce que la livraison signée ne couvre pas. Lors de la démonstration, la demande d'une banque fictive de bloquer les gros virements vers de nouveaux bénéficiaires a produit une véritable pull request sur un dépôt de paiements de démonstration, issue d'une usine à cinq contrats et onze vérifications ; d'après l'auteur, le contrôle a pris 22 secondes.

Meppiel ne cache pas les limites. Un feu vert indique quelle usine approuvée a produit le changement et quelles vérifications ont réussi, pas que le code est juste : il ne vaut que ce que valent les vérifications. Aucun niveau de build SLSA n'est revendiqué, les modèles sont consignés sans être vérifiés, la révocation bloque les nouvelles livraisons sans rappeler le code déjà fusionné, et les reçus produits sur un ordinateur portable ne sont pas signés. Il souligne aussi que la liste des compétences données à un agent ne prouve pas qu'il les a suivies.

Du code accompagne la proposition, dans deux projets open source créés par Meppiel. APM, l'Agent Package Manager de Microsoft, installe les usines et fige chaque compétence sur un commit et une empreinte de contenu, sous une politique unique pour toute l'organisation ; l'essai précise que Dependabot prend désormais en charge les mises à jour de version d'APM. APMX, qu'il décrit comme une implémentation indépendante et expérimentale, exécute les usines sur l'agent choisi, rédige les reçus et fournit le contrôle avec la commande apmx audit. Il affirme qu'aucun des deux n'est imposé par le format et invite les communautés SLSA, in-toto et CycloneDX, comme tout autre contributeur, à critiquer la version de travail dans les discussions GitHub.

Références