Un meilleur prompt peut améliorer une réponse.

Il ne peut pas définir, à lui seul, une frontière opérationnelle.

Cette différence devient essentielle dès qu’un système d’IA cesse de se comporter comme un simple assistant et commence à agir. Lorsqu’un agent peut appeler des outils, modifier un état, engager des dépenses, ouvrir des pull requests, changer une configuration, produire des artefacts ou déclencher un autre agent, l’organisation a besoin de quelque chose de plus solide qu’un texte lui demandant d’être prudent.

Cet article est la cinquième partie de la série en dix volets AI Governance in an AI-Native Software Development Company. La partie 4, The Executable Policy Layer, a montré que la gouvernance ne devient réelle que lorsque la politique atteint le chemin d’exécution. Cette partie se rapproche encore de l’agent : que peut-il faire exactement, dans quelles conditions, avec quels outils, et que doit-il se passer lorsque ces conditions ne sont pas réunies ?

La réponse est un contrat.

Les prompts expriment l’intention. Les contrats encadrent le comportement.

Un prompt n’est pas une frontière de contrôle

Les prompts sont utiles parce qu’ils sont flexibles.

C’est aussi pour cette raison qu’ils sont faibles comme contrats.

Un prompt peut dire :

« Examine ce déploiement avec prudence. N’effectue pas de changement risqué. Demande une approbation lorsque c’est nécessaire. »

Un humain peut déduire beaucoup de choses de cette phrase. L’agent, lui, doit reconstruire les règles manquantes à chaque exécution.

Qu’est-ce qu’un risque important ?

Quel environnement est autorisé ?

Quels outils peuvent être utilisés ?

Quelles preuves doivent exister avant une approbation ?

Quel budget peut être consommé ?

Que faire si les preuves sont incomplètes ?

Qui peut autoriser une exception ?

Quelle structure de sortie les systèmes en aval doivent-ils recevoir ?

Que se passe-t-il si le modèle, le schéma d’un outil ou le runtime change ?

Le prompt ne répond pas à ces questions. Il les suggère.

Cela peut suffire pour un assistant à faible enjeu. Pas pour un système qui dispose d’une véritable autorité.

Le runtime finit toujours par trancher.

Quelle que soit l’intention du prompt, le comportement réel dépend des capacités exposées par le runtime et des limites qu’il fait effectivement respecter.

La pile contractuelle

Une séparation utile consiste à considérer que :

  • les prompts expriment l’intention
  • les fichiers d’instructions fournissent le contexte
  • les skills et les règles définissent le contrat de travail
  • les points d’enforcement rendent ce contrat contraignant
  • la vérification au runtime produit une attestation
  • les preuves et les refus créent l’enregistrement durable

Les termes varient selon les plateformes. La séparation des responsabilités ne devrait pas varier.

Un prompt peut dire ce que l’agent devrait accomplir.

Un contrat dit ce qu’il est autorisé à faire pour y parvenir.

C’est la différence entre un conseil et une autorité.

Que doit contenir un contrat d’agent ?

Un contrat d’agent n’a pas besoin de commencer par un immense schéma de gouvernance.

Il doit surtout rendre explicites les hypothèses jusque-là implicites.

Dans la pratique, un contrat utile couvre au minimum les dimensions suivantes.

Identité et responsabilité

Chaque agent ou capacité déployée doit avoir une identité stable, une version et un responsable.

Il faut pouvoir répondre à ces questions :

  • quel agent agit
  • quel bundle de capacité est actif
  • qui possède le contrat
  • quand il a été approuvé
  • quand il expire ou doit être revu

Un agent non identifié utilisant un compte de service partagé est déjà difficile à gouverner.

Objectif et non-objectifs

Définissez ce que l’agent existe pour faire et ce qu’il ne doit explicitement pas faire.

« Aider aux déploiements » est vague.

« Évaluer les preuves de déploiement du service X et recommander allow, deny ou human review ; ne jamais exécuter le déploiement en production » est un contrat.

Les non-objectifs sont importants parce que l’autonomie s’étend souvent par ambiguïté.

Périmètre des outils et des ressources

Listez les outils que l’agent peut appeler et les ressources que ces outils peuvent atteindre.

Le contrat doit distinguer :

  • lecture et écriture
  • développement, staging et production
  • un dépôt et tous les dépôts
  • un tenant et tous les tenants
  • observation et mutation

La présence d’un outil dans le runtime ne doit pas signifier automatiquement que l’agent est autorisé à l’utiliser.

Entrées et préconditions

Définissez ce qui doit être vrai avant l’exécution.

Par exemple :

  • champs obligatoires de la requête
  • preuves nécessaires
  • version de politique requise
  • délégation humaine valide
  • état nécessaire de l’environnement
  • âge maximal des informations récupérées

Si une précondition manque, le système doit savoir s’il faut refuser, différer ou escalader.

Sorties et postconditions

Les systèmes en aval ne devraient pas avoir à deviner ce que l’agent voulait dire.

Le contrat doit définir :

  • le schéma de sortie
  • les références de preuve obligatoires
  • les champs d’incertitude si nécessaire
  • les états de décision autorisés
  • les effets de bord attendus
  • les conditions qui doivent rester vraies après l’exécution

Le langage naturel peut faire partie de la sortie, mais la partie exploitable par une machine ne doit pas dépendre uniquement de l’interprétation d’un texte libre.

Risque, blast radius et budgets

Le contrat doit préciser le niveau d’autorité que la capacité peut exercer.

Cela va au-delà des permissions.

Les limites utiles incluent notamment :

  • classe d’action maximale
  • blast radius maximal
  • budget financier
  • budget de tokens
  • budget de temps ou de nombre d’étapes
  • limite de concurrence
  • enveloppe de rate limit

C’est dans le contrat que la question « jusqu’où cela peut-il aller ? » reçoit une réponse explicite.

Refus et escalade

Un refus n’est pas nécessairement un échec du modèle.

Dans un système gouverné, il peut être le bon résultat.

Le contrat doit indiquer quand l’agent doit s’arrêter, quand il peut dégrader proprement le service, quand il doit demander une approbation et quand il doit mettre une sortie en quarantaine plutôt que de l’envoyer dans le chemin actif.

Si le comportement de refus n’est pas défini, l’agent doit improviser exactement au moment où l’organisation a le plus besoin d’un comportement déterministe.

Preuves

Toute action importante doit laisser assez de preuves pour reconstruire pourquoi elle s’est produite.

Le contrat peut exiger :

  • les entrées consultées
  • les références de connaissance ou de source
  • les appels d’outils
  • la version de politique
  • la version du contrat
  • la raison de la décision
  • les approbations
  • les exceptions
  • les effets de bord produits

C’est à ce stade que le comportement de l’agent devient auditable plutôt qu’anecdotique.

Les prompts sont lus. Les enregistrements doivent pouvoir être prouvés.

Un contrat peut rester petit

La première version peut être volontairement simple.

Par exemple :

~~~yaml agent_contract: id: deployment-reviewer version: 3 purpose: review deployment evidence

allowed_tools:

  • read_repository
  • read_ci_results
  • read_runtime_health

forbidden_actions:

  • deploy_production
  • modify_secrets

preconditions:

  • deployment_evidence_present
  • active_policy_version_present

outputs: schema: deployment_review_v2 allowed_decisions:

  • allow
  • deny
  • require_approval

escalation: when:

  • evidence_incomplete
  • blast_radius_above_medium

evidence: required:

  • sources_used
  • policy_version
  • contract_version
  • decision_reason

~~~

La syntaxe n’est pas l’essentiel.

Le changement important est que les hypothèses sont désormais visibles, testables et versionnables.

Une équipe peut relire cet artefact.

Un pipeline peut le valider.

Le runtime peut en faire respecter certaines parties.

Un système d’évaluation peut tester le comportement contre lui.

Un reviewer d’incident peut demander quelle version était active.

C’est déjà bien plus robuste que « sois prudent ».

Un skill n’est pas un contrat à lui seul

Les plateformes d’agents modernes regroupent de plus en plus les capacités dans des skills, règles, fichiers d’instructions, manifests ou bundles d’outils.

C’est un progrès utile.

Mais un skill qui explique comment accomplir une tâche n’est pas automatiquement un contrat de gouvernance.

Un skill peut expliquer comment déployer un service.

Le contrat doit encore répondre à ces questions :

  • cet agent peut-il déployer ce service
  • dans quel environnement
  • sous la délégation de qui
  • avec quelles preuves
  • dans quel blast radius
  • avec quel budget
  • avec quelle version du skill
  • avec quelles exigences de rollback ou de containment

Le même skill peut être sûr pour un agent et inadapté pour un autre.

Le même outil peut être acceptable en staging et interdit en production.

La même intention peut être autorisée dans un contexte normal et nécessiter une approbation pendant un incident.

Capacité et autorité sont deux choses différentes.

Une règle simple :

Un skill dit à l’agent comment faire. Un contrat dit au système si l’action est autorisée, où et sous quelles conditions.

Le contrat doit résister au drift du runtime

Même un bon contrat perd tout son sens si la surface comportementale change en dessous de lui sans contrôle.

Le comportement peut évoluer lorsque changent :

  • le modèle
  • le system prompt
  • le fichier d’instructions
  • le skill
  • le schéma d’outil
  • les permissions
  • le routage
  • les sources de retrieval
  • le bundle de politique
  • l’hôte d’exécution

Le contrat doit donc se lier à des versions précises, pas à des noms qui peuvent dériver silencieusement.

« Utiliser l’agent de code » ne suffit pas.

« Utiliser le bundle de capacité 4.7 sous le contrat 3.2 et le bundle de politique 12 » est gouvernable.

Le contrat n’a pas pour but de figer le système pour toujours.

Il crée un endroit où le changement devient visible.

Lorsqu’une mise à niveau du modèle ou d’un skill modifie le comportement, le bundle de capacité change. Le contrat peut être réévalué, retesté et réapprouvé.

Sans cette discipline, le contrat devient une documentation décrivant un système qui n’existe plus.

La vérification au runtime est l’autre moitié du contrat

Écrire le contrat ne suffit pas.

Le système doit vérifier que l’exécution est restée dans ses limites.

Cette vérification peut inclure des contrôles déterministes :

  • seuls les outils autorisés ont été appelés
  • les ressources interdites n’ont pas été touchées
  • les preuves requises étaient présentes
  • les budgets ont été respectés
  • la sortie correspondait au schéma prévu
  • l’escalade a eu lieu lorsque le seuil a été dépassé

Elle peut aussi inclure une évaluation comportementale lorsque les contrôles déterministes ne suffisent pas.

Le résultat doit devenir une attestation reliée à la trace d’exécution.

La bonne question n’est pas seulement :

« L’agent a-t-il terminé ? »

Mais :

« L’agent a-t-il terminé dans les limites du contrat ? »

C’est une définition beaucoup plus forte du succès.

Le refus fait partie du produit

Les équipes optimisent souvent fortement le taux de complétion.

Cela pousse facilement à considérer les refus et les escalades comme des échecs.

La gouvernance exige un autre regard.

Un bon agent doit refuser lorsque :

  • les preuves nécessaires manquent
  • l’autorité demandée dépasse son périmètre
  • l’appelant ne dispose pas de la délégation nécessaire
  • l’action dépasserait sa limite de blast radius
  • le budget est épuisé
  • l’état de la politique est ambigu
  • le runtime ne peut pas prouver qu’un contrôle obligatoire est actif

Un refus accompagné d’une raison structurée n’est pas une sortie inutile.

C’est un résultat gouverné.

Il en va de même pour « require approval », « defer » et « quarantine ».

Lorsque ces états sont explicitement représentés dans le contrat, le système peut les router sans obliger le modèle à inventer un mécanisme de récupération.

Le contrat doit être testable

Si une clause du contrat ne permet pas de produire un test, elle est probablement encore trop vague.

Pour chaque clause importante, demandez quelle preuve démontrerait la conformité.

Si le contrat dit que l’agent ne peut pas déployer en production, exposez l’outil de déploiement dans un test et vérifiez que le runtime le bloque.

Si l’escalade est obligatoire au-dessus d’un seuil de blast radius, testez exactement cette limite.

Si la sortie doit contenir des références de preuve, rejetez les sorties qui les omettent.

Si un budget doit arrêter le workflow, poussez l’agent jusqu’à la limite dans un environnement non productif et observez le résultat.

Le contrat prend de la valeur lorsqu’il est relié à l’évaluation.

Sinon, il devient simplement un autre document qui dérivera avec le temps.

Ordre pratique de mise en œuvre

Ne commencez pas par concevoir un langage contractuel à l’échelle de l’entreprise.

Commencez par une capacité réelle.

1. Choisissez un agent capable de produire un effet de bord

Les assistants en lecture seule sont utiles, mais ils cachent les questions de gouvernance les plus difficiles.

Choisissez une capacité qui peut changer un état, dépenser de l’argent, ouvrir une PR, modifier une configuration ou déclencher un déploiement.

2. Écrivez le plus petit contrat explicite

Définissez l’identité, l’objectif, les non-objectifs, les outils, les ressources, les préconditions, les sorties, la limite de risque, les refus, les escalades et les preuves.

Gardez le contrat assez petit pour que l’équipe propriétaire puisse réellement le relire.

3. Liez le contrat aux versions

Épinglez le modèle, le prompt, les skills, les outils, le bundle de politique et les hypothèses du runtime qui influencent matériellement le comportement.

Traitez toute modification de ces éléments comme un changement de capacité.

4. Faites respecter les limites dures hors du modèle

Ne demandez pas au modèle de surveiller lui-même ses permissions les plus risquées.

Le runtime doit bloquer les actions qui dépassent le contrat.

5. Émettez les preuves du contrat

Associez la version du contrat et les principaux signaux de conformité à la même trace que l’action.

L’exécution doit pouvoir être reconstruite.

6. Testez les refus et les escalades

N’évaluez pas uniquement le chemin idéal.

Forcez l’absence de preuves, le dépassement de périmètre, la pression budgétaire et l’ambiguïté de politique.

Vérifiez que le système échoue exactement de la manière prévue par le contrat.

7. Traitez les contrats comme des artefacts opérationnels

Ils doivent avoir un propriétaire, une version, une date de revue et un chemin de retrait.

Ils appartiennent au cycle de vie de la production.

Conclusion

Le prompt ne disparaît pas.

Il retrouve simplement sa bonne place.

Les prompts sont excellents pour exprimer des objectifs, du contexte, un ton, une stratégie et un raisonnement flexible.

Ils sont de mauvais substituts aux frontières d’autorité.

Une organisation AI-native a besoin des deux.

Le prompt dit ce que l’humain veut.

Le contrat dit au système ce que l’agent est autorisé à faire pour atteindre cet objectif.

La couche d’enforcement rend le contrat réel.

Les preuves du runtime montrent s’il a été respecté.

Et le refus offre une manière légitime de s’arrêter lorsque les conditions contractuelles ne sont pas satisfaites.

La progression devient :

intention -> contrat -> enforcement -> attestation -> preuve.

Le contrat devient une spécification comportementale exécutable entre les humains, les agents et les outils.

Non pas parce que les agents ont besoin de plus de bureaucratie.

Mais parce qu’une autonomie sans contrat revient à donner un accès aux outils à une interprétation sans limites.

L’article suivant part d’une hypothèse moins confortable : l’agent sortira parfois de son contrat malgré tout.

C’est là que le containment commence.

Prochaine partie : AI Governance Fails Without Containment.

Publié initialement par Reza Arani sur Medium le 29 mai 2026. Adapté pour Aipolix comme cinquième partie de la série AI Governance in an AI-Native Software Development Company.