Les agents IA qui modifient les feature flags : contrôler chaque écriture

Les agents IA qui modifient des feature flags doivent être traités comme des écritures en production, car c'est exactement ce qu'ils sont. Un flag peut se trouver en dehors du pipeline de déploiement, tout en activant du code pour les clients, en masquant un parcours de paiement, en élargissant une expérimentation ou en désactivant un contrôle de sécurité en quelques secondes.

L'erreur que je rencontre sans cesse consiste à donner à un agent accès à un fournisseur de flags parce que la tâche paraît anodine : « active le nouveau parcours pour les utilisateurs internes » ou « ramène le déploiement à zéro ». La modification peut être correcte. C'est l'absence de trace qui est dangereuse. Après une panne, il faut savoir ce que l'agent a demandé, qui a accepté la demande, ce que le fournisseur a fait et si l'état final correspondait à la demande. Une transcription de conversation ne peut pas porter cette responsabilité.

Une mutation de flag est une écriture en production

La mise à jour d'un feature flag a la même nature opérationnelle que la modification d'un paramètre d'une base de données de production ou d'une règle de routage active. L'appel API peut être court, mais son effet peut être large et immédiat.

Traiter les flags comme une configuration sans danger mène à un échec bien connu. Un agent analyse une hausse du taux d'erreur, trouve un flag associé à la fonctionnalité récente et le définit sur false. Cela peut protéger les utilisateurs. Mais cela peut aussi désactiver un parcours sans rapport, parce que le flag utilise une règle de ciblage plutôt qu'un simple booléen, ou parce que l'agent a sélectionné le mauvais environnement. Si personne ne peut identifier la mutation exacte demandée et l'humain qui l'a approuvée, l'équipe passe l'incident à discuter du passé au lieu de rétablir le service.

L'article de Martin Fowler sur les Feature Toggles établit une distinction que les équipes ont souvent tendance à gommer. Les toggles de release, d'expérimentation, d'exploitation et de gestion des permissions n'ont ni la même durée de vie ni le même degré de dynamisme. Cette distinction doit modifier les contrôles appliqués à l'action d'un agent. Un toggle opérationnel qui désactive une intégration défaillante peut nécessiter une approbation humaine rapide. Un toggle de gestion des permissions qui modifie l'accès à des données réglementées mérite un processus beaucoup plus strict. Appeler les deux « un flag » ne dit presque rien du risque.

Les modifications de flags contournent aussi les contrôles que les ingénieurs associent aux déploiements de code. Une pull request peut montrer une revue par les pairs, un build peut afficher les résultats des tests et une release peut indiquer la version de l'artefact. Un appel au fournisseur de flags peut ne montrer qu'un nom de token et un horodatage. Si un processus autonome possède le token, ce nom peut même être partagé entre de nombreuses exécutions.

Posez la même question qu'avant toute écriture en production : quel état précis cette demande va-t-elle modifier, sous quelle autorité et comment prouverons-nous l'état obtenu ?

Une lecture est différente. Un agent peut inspecter un flag, son environnement et ses règles actuelles pour préparer une recommandation. Une écriture modifie un système externe. Ne regroupez pas ces permissions simplement parce qu'une intégration rend la chose pratique.

Séparer l'intention, l'autorisation, l'exécution et l'état observé

Un seul événement ne suffit pas à décrire une action sur un feature flag. Un enregistrement fiable contient quatre faits différents. Les confondre masque l'échec que vous devrez diagnostiquer plus tard.

L'intention correspond à ce que l'agent a demandé. Elle doit nommer un identifiant de flag stable, un environnement, la valeur demandée ou la modification de règle, la raison et le périmètre. Elle doit être enregistrée avant l'appel au fournisseur.

L'autorisation indique qui a permis cette intention. Une approbation humaine doit être liée à la modification proposée avec précision, et non à une demande vague comme « autoriser l'agent à gérer les flags ». L'approbateur doit disposer de suffisamment de contexte pour décider : environnement cible, état actuel, état proposé, segment concerné, date d'expiration éventuelle et tâche ou incident à l'origine de la demande.

L'exécution enregistre la demande sortante et la réponse du fournisseur. Elle prouve que la passerelle a tenté d'appliquer l'action approuvée. Elle ne prouve pas que l'état souhaité existe.

L'état observé provient d'une nouvelle lecture du flag après l'écriture. Il permet de détecter les charges utiles mal formées, les mises à jour partielles, les comportements par défaut et les appels envoyés au mauvais projet ou au mauvais environnement. Cette lecture a toutefois ses limites. Des clients SDK mis en cache peuvent ne pas avoir récupéré la configuration modifiée, et elle ne peut pas prouver que le code derrière le flag fonctionne correctement. Ces éléments doivent être observés séparément dans les données de télémétrie du déploiement et la surveillance applicative.

Cette distinction compte lors d'une restauration. Supposons qu'un agent demande checkout_v2=false, qu'un humain l'approuve et que le fournisseur renvoie un succès. Si un second opérateur modifie le flag avant que l'agent ne le relise, un journal naïf racontera une histoire cohérente mais fausse. Un enregistrement correct indiquera que la demande approuvée a réussi à la frontière API, puis rapportera l'état observé, y compris une version ou une révision si le fournisseur en expose une.

Ne laissez pas une raison en texte libre remplacer ces champs. « Réduire les erreurs de paiement » fournit un contexte utile. Ce n'est ni une cible, ni une ancienne valeur, ni une nouvelle valeur approuvée, ni un résultat final.

Capturer une enveloppe de mutation avant l'appel au fournisseur

L'agent doit envoyer une demande de modification structurée, et non composer une requête HTTP arbitraire vers le fournisseur de flags. Une enveloppe fixe produit un objet qu'un réviseur peut lire et qu'une passerelle peut valider.

Cet exemple utilise un flag booléen, mais la même structure s'applique à une configuration JSON, aux déploiements en pourcentage et aux règles de ciblage. Gardez les modifications de règles séparées des changements de valeurs scalaires. Une règle de ciblage peut modifier l'exposition bien davantage que ne le laisse penser une simple valeur true ou false.

{
  "request_id": "ffchg_01J8KQ4W6D7P",
  "correlation_id": "incident_INC-1842",
  "operation": "set_boolean_flag",
  "flag": {
    "project": "storefront",
    "environment": "production",
    "name": "checkout_v2"
  },
  "expected": {
    "value": true,
    "revision": "481"
  },
  "requested": {
    "value": false
  },
  "reason": "Reduce checkout failures while payment timeout is investigated",
  "rollback": {
    "value": true,
    "expires_at": "2025-03-08T18:00:00Z"
  }
}

Le bloc expected empêche un écrasement silencieux. Il signifie : n'appliquez cette mutation que si la valeur et la révision actuelles correspondent encore à celles que le demandeur a consultées. Si un autre humain ou une autre automatisation a modifié le flag après la lecture de l'agent, rejetez la demande et affichez le nouvel état. Réessayer aveuglément serait une mauvaise réponse. L'agent doit redemander une autorisation, car le fondement de son action a disparu.

Le request_id doit être idempotent. Des erreurs réseau surviennent après la réception d'une demande par le fournisseur, mais avant que l'appelant ne reçoive la réponse. Sans idempotence, une nouvelle tentative de l'agent peut créer des événements d'audit en double ou appliquer deux fois une règle en pourcentage lorsque le fournisseur modélise les mises à jour sous forme de patchs. Stockez l'identifiant de la demande et renvoyez le résultat d'origine lorsqu'une soumission est répétée.

Une passerelle peut renvoyer un résultat sous cette forme :

{
  "request_id": "ffchg_01J8KQ4W6D7P",
  "status": "applied",
  "provider_request_id": "p_9d3ab",
  "authorization": {
    "approver": "[email protected]",
    "approved_at": "2025-03-08T17:18:32Z"
  },
  "observed": {
    "value": false,
    "revision": "482",
    "read_at": "2025-03-08T17:18:35Z"
  }
}

N'incluez aucun token du fournisseur dans ces enregistrements. Un journal de demandes qui contient des identifiants finit par devenir un second coffre de secrets, généralement avec des contrôles d'accès moins bons et davantage de copies.

Une approbation doit décrire le rayon d'action

Un humain ne peut pas approuver une modification sûre à partir du seul nom d'un flag. Les noms évoluent, les flags survivent à leur intention initiale et un booléen peut dissimuler une vaste règle de ciblage derrière un intitulé rassurant.

La fiche d'approbation ou l'écran de revue doit afficher la représentation actuelle à côté de la représentation demandée. Pour un déploiement en pourcentage, indiquez les anciens et nouveaux pourcentages exacts, la population ou le segment, tout flag prérequis et l'environnement. Pour une modification de règle, affichez la règle complète avant et après dans une forme canonique lisible. Une différence qui omet une clause parce qu'elle semble répétitive peut transformer accidentellement « employés de la région A » en « tous les utilisateurs ».

L'approbateur a également besoin de la raison et de la date d'expiration. Les modifications opérationnelles temporaires ont tendance à devenir permanentes, car l'incident se termine et chacun passe à autre chose. Une expiration n'est pas une restauration automatique magique. Elle donne à un opérateur un moment prévu pour réévaluer le flag et crée un engagement visible dans l'enregistrement de l'action.

Le périmètre de l'approbation doit correspondre à la mutation, pas à l'agent. « Approuver ce processus pour le reste de la session » peut convenir à des inspections répétées ou à un ensemble prédéfini d'actions hors production. Ce périmètre est mal adapté à un déploiement en production où chaque action modifie une population différente de clients.

Je demanderais une approbation distincte pour chaque mutation en production dans les cas suivants :

• La modification concerne un contrôle opérationnel, les paiements, l'authentification, l'autorisation ou la conservation des données.
• La demande modifie une règle de ciblage, un segment, un prérequis ou un pourcentage plutôt qu'une seule valeur booléenne.
• L'action cible la production ou un environnement relié à un trafic client réel.
• L'agent propose une valeur différente de celle d'un plan de restauration approuvé.

Ce n'est pas une approbation de façade. Le rôle de l'humain n'est pas de recopier la demande. Il doit décider si le périmètre indiqué et la situation opérationnelle présente justifient l'écriture. Si la fiche masque le périmètre, la personne ne peut que l'approuver machinalement.

Évitez une approbation permanente indiquant qu'un agent peut « gérer les feature flags ». Elle est tentante parce qu'elle supprime les interruptions. Mais elle transforme chaque mutation ultérieure en écriture non revue en production, y compris celle qui survient lorsque l'agent est induit en erreur par un contexte obsolète ou un résultat d'outil trompeur.

La concurrence rend les restaurations automatisées dangereuses par défaut

Un agent ne peut restaurer un flag que s'il prouve qu'il annule sa propre modification. Le conseil courant « faites toujours restaurer l'agent en cas d'échec » ignore les opérateurs concurrents et présente un risque.

Considérez cette séquence. À 10 h 00, la valeur actuelle est true, révision 481. L'agent reçoit l'autorisation de la définir sur false, et le fournisseur enregistre la révision 482. À 10 h 06, un ingénieur d'astreinte observe un autre symptôme et définit volontairement le flag sur true, révision 483. À 10 h 08, la condition de surveillance de l'agent se déclenche et il exécute la restauration prévue vers true.

Dans ce cas précis, la valeur identique semble sans conséquence, mais le même scénario avec une règle de ciblage peut causer des dommages. L'ingénieur d'astreinte a peut-être modifié la règle pour limiter un parcours à un seul tenant. L'agent restaure l'ancienne règle générale parce qu'il se souvient d'un instantané antérieur à sa modification. Il vient d'écraser une intervention volontaire sans même la voir.

Une demande de restauration doit inclure la révision créée par l'action originale comme état attendu. La passerelle ne doit appliquer la restauration que si le fournisseur rapporte encore cette révision, ou exactement la configuration canonique écrite par l'agent. Si la condition échoue, renvoyez needs_review avec la configuration actuelle. L'agent peut expliquer le conflit à un humain, mais ne doit pas le résoudre lui-même.

Utilisez une charge utile de restauration qui porte l'action parente :

{
  "request_id": "ffrb_01J8KR0Y8J2M",
  "operation": "rollback_boolean_flag",
  "parent_request_id": "ffchg_01J8KQ4W6D7P",
  "flag": {
    "project": "storefront",
    "environment": "production",
    "name": "checkout_v2"
  },
  "expected": {
    "value": false,
    "revision": "482"
  },
  "requested": {
    "value": true
  }
}

Certains fournisseurs n'exposent ni les révisions ni les API de mise à jour conditionnelle. Dans ce cas, vous ne pouvez pas rendre une restauration automatique suffisamment sûre pour un flag de production contesté. Lisez l'état, présentez la différence et demandez une approbation humaine pour l'écriture de restauration. Accepter cette limite vaut mieux que de prétendre qu'un horodatage fournit un contrôle de concurrence.

Distinguez également la restauration d'un feature flag de la récupération de l'état des utilisateurs. Désactiver un flag peut arrêter l'exposition future, mais cela n'annule ni les migrations de données, ni les tâches en file d'attente, ni les enregistrements créés pendant l'activation de la fonctionnalité. Le contexte de l'approbation doit le dire clairement lorsqu'un flag contrôle des écritures.

Restreindre les opérations, les cibles et les identifiants

Un agent doit pouvoir demander un vocabulaire restreint d'actions sur les flags, et non disposer d'un accès administrateur au fournisseur. Le token ou l'identifiant API du fournisseur doit rester en dehors du contexte de l'agent.

Commencez par lister les opérations autorisées. get_flag et list_flag_metadata sont des lectures. set_boolean_flag est une écriture limitée. set_rollout_percentage, replace_targeting_rule, create_flag, archive_flag et edit_segment ont des conséquences bien plus importantes et doivent correspondre à des opérations distinctes. N'exposez pas une action générique PATCH /flags/{id} en supposant que les instructions suffiront à rendre l'agent prudent. Les endpoints de patch génériques invitent à envoyer des champs qu'aucun réviseur n'attendait.

Limitez ensuite les cibles. Liez un identifiant à un projet et à un environnement lorsque le fournisseur permet ce niveau de restriction. Dans la passerelle d'action, maintenez une liste autorisée d'identifiants de flags et d'opérations pour la tâche concernée. Un agent de release qui possède checkout_v2 n'a pas besoin d'accéder à tous les flags de l'organisation.

Une demande d'action doit échouer avant d'atteindre le fournisseur si elle tente une opération non approuvée, un environnement inconnu, une révision attendue absente ou une cible interdite. Cette validation doit être déterministe. Une règle en langage naturel comme « n'effectuer que des changements sûrs » donne à l'agent une phrase à interpréter, pas une limite à faire respecter.

Sallyport conserve les identifiants HTTP dans son coffre chiffré et effectue l'appel API sans transmettre le secret à l'agent. Ce fonctionnement convient bien à ce modèle : l'agent peut demander une action tandis que l'identifiant reste sur le Mac de contrôle.

Conservez séparément l'identifiant du fournisseur et l'identité propre de l'agent. L'historique d'audit du fournisseur ne verra peut-être qu'un seul compte de service, mais votre enregistrement d'action peut identifier la session de l'agent, la tâche source et l'humain qui a approuvé l'écriture précise. Cette séparation facilite aussi la révocation : vous pouvez arrêter une exécution d'agent sans renouveler un identifiant utilisé par un processus humain légitime.

Ne placez pas un token API dans un fichier de configuration d'agent « juste pour l'incident ». Les agents copient plus facilement qu'on ne le pense le contexte dans les transcriptions, l'historique du shell, les patchs générés et les arguments des outils. Renouveler le token plus tard n'efface pas ces copies.

Tester le chemin de contrôle avec des échecs, pas seulement le cas idéal

Une intégration de feature flags n'est prête qu'après avoir vérifié son comportement lorsque ses hypothèses échouent. Le parcours idéal, lire la valeur, approuver, mettre à jour la valeur, ne prouve presque rien.

Effectuez un test contrôlé dans un environnement hors production et provoquez volontairement les situations suivantes :

1. Modifiez le flag après sa lecture par l'agent, puis envoyez la demande originale. La passerelle doit rejeter la révision attendue devenue obsolète.
2. Envoyez deux fois le même identifiant de demande après avoir simulé une réponse perdue. Le second appel doit renvoyer le premier résultat enregistré et ne pas créer une nouvelle mutation.
3. Refusez l'approbation. Le fournisseur ne doit recevoir aucune écriture et le journal d'audit doit indiquer un refus, plutôt qu'un délai d'attente ambigu.
4. Faites modifier le flag par un humain après l'action de l'agent, puis tentez une restauration automatique. La restauration doit s'arrêter pour revue.
5. Verrouillez ou révoquez la session de l'agent pendant une demande en attente. L'action doit échouer avant l'utilisation des identifiants.

Ces tests révèlent un problème de conception subtil : de nombreuses équipes n'enregistrent que les modifications réussies. Les demandes échouées et refusées sont tout aussi importantes. Une demande refusée montre qu'un agent a tenté d'accéder à un périmètre qui ne lui était pas attribué. Un rejet pour écriture obsolète montre que le système a empêché un écrasement. Ces deux enregistrements expliquent pourquoi l'état du fournisseur n'a pas changé alors qu'un opérateur s'y attendait.

Testez aussi la canonisation. Deux règles de ciblage JSON peuvent avoir le même sens tout en présentant leurs champs dans un ordre différent. Si votre logique compare-et-définis compare le JSON brut, elle produira de faux conflits. Si elle normalise trop, elle risque de manquer une différence sémantique. Choisissez une représentation canonique du modèle du fournisseur, enregistrez-la et testez-la avec des champs réordonnés, des valeurs par défaut omises et des références équivalentes à des segments.

Enfin, testez le cas où le fournisseur renvoie un succès mais où la nouvelle lecture échoue. Enregistrez execution=accepted et observed=unknown; ne qualifiez pas la demande globale de réussie. Quelqu'un doit inspecter l'état du fournisseur avant que l'agent n'effectue une modification qui en dépend.

Un journal d'audit doit résister à un incident contesté

Un enregistrement utile de feature flag doit répondre à une question sceptique : « Comment savons-nous que ce récit de la modification n'a pas été édité après coup ? » Les journaux applicatifs ordinaires suffisent souvent au débogage, mais répondent rarement à cette question lorsque de nombreuses personnes peuvent accéder au système de journalisation.

Écrivez des événements d'action append-only avec un numéro de séquence, un horodatage, l'enveloppe de la demande, le résultat de l'autorisation, le résultat de l'exécution et l'état observé. Reliez les événements associés par des identifiants de demande et des identifiants de demande parente. Le chaînage par hachage rend les modifications ultérieures visibles : chaque événement contient une empreinte de son propre contenu et l'empreinte de l'événement précédent. La vérification examine la chaîne dans l'ordre.

Le chaînage par hachage ne rend pas un journal vrai. Il ne peut pas prouver que la personne ayant approuvé une demande l'avait comprise et ne peut pas récupérer des enregistrements qui n'ont jamais été écrits. Il permet de détecter une suppression ou une modification a posteriori lorsque la chaîne est conservée et vérifiée indépendamment. C'est la bonne promesse à faire, et elle est déjà plus utile que de qualifier un journal d'« immuable » sans décrire le mécanisme.

Conservez l'historique natif du fournisseur de flags comme preuve complémentaire, pas comme seul enregistrement. Faites correspondre les identifiants des demandes du fournisseur lorsqu'ils sont disponibles. Reliez l'identifiant de corrélation de l'action à un incident ou à une modification de déploiement. Lorsqu'une personne demande pourquoi un flag a changé, vous devez pouvoir retracer la décision sans la reconstituer à partir de messages et de souvenirs humains.

Sallyport projette les enregistrements de session et d'appels individuels à partir d'un journal d'audit chiffré et chaîné par hachage. La commande sp audit verify vérifie la chaîne hors ligne sans clé du coffre. Une équipe peut ainsi vérifier que son historique d'actions de contrôle reste cohérent même lorsque le coffre est verrouillé.

Examinez les actions refusées et les conflits d'écriture obsolète dans le cadre du travail opérationnel normal. Ce ne sont pas des bruits parasites. Une hausse des conflits peut montrer que plusieurs automatisations contrôlent les mêmes flags. Des demandes répétées vers des cibles refusées peuvent indiquer que le périmètre de la tâche de l'agent est trop large ou mal défini.

Faire d'abord produire à l'agent une proposition de modification

Le modèle opérationnel le plus sûr est simple : laissez l'agent inspecter, diagnostiquer et rédiger la mutation, puis exigez qu'un chemin d'écriture contrôlé l'exécute. La proposition doit être assez détaillée pour qu'un autre ingénieur puisse l'approuver sans lire toute la transcription de l'agent.

Pour chaque demande de production, exigez que l'agent indique l'état actuel observé, l'état exact souhaité, la révision attendue, la raison pour laquelle la modification aide, ce qui pourrait être touché et la condition de restauration. S'il ne peut pas fournir ces informations, il n'a pas encore gagné le droit d'écrire.

Ne demandez pas un long essai. Demandez une demande complète. La différence est importante. Un long texte peut cacher le fait que l'agent n'a jamais vérifié l'environnement cible ou n'a jamais récupéré la règle actuelle. Une enveloppe structurée révèle immédiatement ce qui manque.

Les équipes qui adoptent cette discipline constatent que de nombreuses modifications proposées ne nécessitent aucune exécution. L'agent peut découvrir que le flag a déjà la valeur souhaitée, que le groupe en échec ne correspond pas à la règle ou qu'une restauration du déploiement est le véritable remède. Lire d'abord et enregistrer l'état attendu empêchent l'agent d'effectuer une écriture de pure forme pour satisfaire une tâche.

Un feature flag est un contrôle rapide du comportement en production. Ne donnez à un agent IA le pouvoir de l'utiliser que si le système enregistre sa demande, lie une décision humaine à la mutation exacte, empêche les écrasements d'états obsolètes et vérifie ce que le fournisseur a stocké. Toute autre approche laisse votre interrupteur de production le plus pratique attaché à un compte que personne ne peut expliquer complètement.