Résumé

  • Le 6 août 2026, l’équipe IETF Tools a prévenu que de grandes pull requests produites avec l’aide de l’IA pourraient saturer les mainteneurs si ceux-ci continuaient à lire chaque ligne. La note évoquait une confiance progressive envers certains contributeurs et une revue moins humaine pour du code à faible impact, tout en précisant que cette approche restait à l’étude.
  • Le guide commun adopté le 25 août n’a pas créé cette voie allégée. Il maintient toutes les contributions dans une file où un ou plusieurs mainteneurs lisent chaque ligne, y compris lorsque le code est généré par une IA.
  • La réponse adoptée agit d’abord sur la qualité de l’entrée : explication humaine proportionnée, petits commits, tests, justification des dépendances, compatibilité avec les règles de l’IETF et engagement durable d’une personne identifiable.
  • Si une exception apparaît plus tard, IETF Tools devrait lui associer une fiche de frontière de revue : périmètre, classe d’impact, auteur de la classification, preuves exigées, profondeur de la revue humaine, rôle de l’IA, autorité de fusion, responsable de maintenance et conditions de retrait.

Une file d’attente peut être attaquée sans qu’un serveur tombe

Dans l’imaginaire de la sécurité, un déni de service ressemble à un flot de paquets dirigé vers une machine. Le problème décrit par IETF Tools est plus subtil : un flot de code plausible dirigé vers une ressource humaine rare.

La mise à jour Tools du 6 août anticipait des pull requests vastes et ambitieuses, assistées par IA, sur la plupart des systèmes de l’IETF. La génération de milliers de lignes peut désormais coûter très peu au demandeur. Leur assimilation sûre reste coûteuse pour l’équipe qui devra exploiter le logiciel, répondre aux incidents et maintenir les choix d’architecture longtemps après la fusion.

La note emploie l’expression de déni de service pour cette asymétrie. Elle ne documente ni attaque, ni panne, ni contribution malveillante. Elle dit qu’une pratique vertueuse — lire chaque ligne — peut devenir le moyen par lequel une file de revue absorbe le temps qui devait servir à corriger les défauts, traiter les urgences et entretenir les applications.

La première décision de gouvernance consiste donc à ne pas confondre ouverture et droit illimité à l’attention. Une communauté peut accueillir des contributions sans promettre d’examiner n’importe quel volume, présenté sous n’importe quelle forme, au coût exclusif des mainteneurs.

Le texte adopté a choisi la discipline d’entrée

La réponse publique a été plus prudente que certaines pistes évoquées pendant la retraite.

Le CONTRIBUTING.md figé au commit du 25 août commence par une règle générale : toute contribution rejoint une file et un ou plusieurs mainteneurs lisent chaque ligne du code proposé. Ce n’est pas une règle spéciale pour l’IA. C’est le régime commun, auquel le code généré par une IA peut être admis.

Le commit 6d3b1c5, daté du 25 août 2026, ajoute les exigences convenues pendant la retraite. Au moment de cette recherche, la version présente sur la branche principale était identique octet pour octet au fichier de ce commit. Il est donc possible de distinguer trois états : les options discutées le 6 août, la règle adoptée le 25, et la règle encore visible au 1er septembre.

Le rapport du directeur exécutif présenté le 1er septembre confirme que les lignes directrices ont été mises à jour afin de recevoir de grandes contributions, notamment générées par IA, sans consacrer la majorité du temps de l’équipe à leur examen. Le rapport ne dit pas qu’une IA a remplacé un mainteneur ni qu’une catégorie à faible impact est entrée en vigueur.

La solution adoptée déplace une partie du coût vers celui qui crée la demande. Une pull request doit expliquer son objet dans un langage humain, avec un niveau de détail proportionné. Les commits doivent être assez petits pour être examinés séparément. Le code doit respecter le style existant, être couvert par des tests conformes à la stratégie du projet, et toute nouvelle dépendance doit être signalée et justifiée. Si le changement suppose une décision de politique communautaire, celle-ci doit précéder la soumission.

Ces exigences transforment un bloc de sortie générée en une série de propositions vérifiables. Elles ne rendent pas le code vrai. Elles rendent sa discussion possible.

Les tests ne remboursent pas automatiquement la dette de compréhension

Il serait tentant de résumer le problème par une formule simple : davantage de tests permettrait moins de lecture. Ce calcul est trop grossier.

Un test répond à une question définie dans un environnement défini. Il peut démontrer qu’une fonction renvoie le résultat attendu sur les cas choisis. Il peut aussi mesurer une propriété d’intégration, une migration ou un comportement sous charge. Mais il ne révèle pas nécessairement qu’une requête base de données, acceptable sur un jeu local, se transforme en tempête SQL en production. Il peut ignorer une dépendance nouvelle, une fuite d’information, un mauvais emplacement de logique ou une conséquence qui n’a jamais été formulée comme assertion.

À l’inverse, la lecture humaine n’est pas infaillible. Un mainteneur fatigué peut traverser chaque ligne sans voir une interaction entre modules. Un outil automatisé peut détecter une répétition ou une branche non testée que l’œil n’a pas remarquée. La bonne politique n’oppose donc pas une lecture sacrée à des tests inférieurs. Elle associe chaque type de preuve à la question qu’il peut effectivement soutenir.

La règle actuelle garde la lecture intégrale comme socle et exige les tests en plus. C’est une position cohérente tant que le volume reste maîtrisable. Si le test devient un substitut à une partie de la lecture, il faudra documenter précisément la substitution : quel risque a été couvert, quelle partie n’a pas été lue et pourquoi le résultat est réputé réversible.

La personne derrière l’agent n’est pas une simple signature

Le passage consacré aux agents de programmation évite une fiction fréquente : prétendre que l’être humain a nécessairement écrit ce qu’il soumet.

Le guide demande autre chose. Le contributeur doit comprendre ce que le code est censé accomplir et comment il s’insère dans l’outil visé. Il doit avoir lu et compris chaque ligne de l’explication destinée aux humains. Si l’IA a produit cette explication ou la documentation, le texte doit être débarrassé de son jargon et rédigé en anglais technique simple.

La nuance est importante. Le document ne contient pas, dans ce passage, une attestation selon laquelle le contributeur comprend chaque ligne de code généré. Il n’impose pas non plus une fiction d’auteur unique. Il fixe un seuil de compréhension fonctionnelle et de qualité documentaire.

Surtout, il transforme le nom attaché à la pull request en engagement de maintenance. La personne promet de corriger les problèmes ultérieurs. À défaut, le code peut être retiré et de futures contributions refusées. Cet engagement ne remplace pas la responsabilité finale de l’équipe qui fusionne et exploite. Il réduit cependant la possibilité de livrer une fonctionnalité ambitieuse puis d’abandonner toute la dette aux mainteneurs.

Le guide prévoit aussi que les contributeurs réguliers utilisant l’IA puissent, avec le temps, devenir connus et dignes de confiance. C’est une observation raisonnable : un historique de corrections, d’explications exactes et de retours rapides après incident contient de l’information.

Mais la confiance porte sur une relation, pas sur l’innocuité d’une ligne de code. Le texte actuel ne définit ni score, ni ancienneté minimale, ni exemption, ni droit de fusion. Tant que la même revue s’applique, cette indétermination est acceptable. Le jour où la confiance réduira le contrôle technique, elle devra devenir une règle explicite et contestable.

La véritable décision se cache dans le mot « impact »

La piste la plus importante de la note d’août concerne les bases de code entretenues avec une forte contribution de l’IA.

Pour les systèmes critiques, l’équipe envisageait de conserver une revue humaine complète. Pour du code jugé peu critique, elle évoquait une vérification centrée sur la qualité des tests et, éventuellement, une revue contradictoire par une autre IA. La note concluait que tout cela restait en discussion.

Le principe de proportionnalité est solide. Une retouche de présentation, facilement annulable, ne mérite pas nécessairement le même investissement qu’un changement d’authentification, de données privées, de métadonnées des standards, de courrier ou d’historique institutionnel. Consacrer le même temps à tous les changements peut lui-même produire du risque en retardant les sujets graves.

Le problème est que « faible impact » ne se trouve pas dans le code comme une couleur naturelle. Il faut choisir l’objet classé. Une petite fonction peut écrire dans une table centrale. Une modification sans données privées peut altérer un registre public sur lequel les participants fondent une décision. Un écran peut sembler cosmétique tout en cachant un état essentiel. Un retour arrière peut restaurer le binaire sans réparer les données déjà modifiées.

Quelqu’un devra donc décider : quelles conséquences comptent, à quel horizon, et sous quelle version de la politique ? Cette personne dépensera le temps futur d’autres mainteneurs et distribuera le risque aux utilisateurs du système. La classification est un acte d’autorité opérationnelle.

La fiche de frontière de revue

Une voie allégée peut être légitime sans publier les prompts, les secrets, les détails d’exploitation ou les données personnelles. Elle doit néanmoins laisser une preuve compacte de la décision.

La première partie de la fiche identifierait le dépôt, le composant, le service ou le registre touché, la pull request et l’ensemble exact des commits. Elle indiquerait, sans fausse précision, si la contribution est humaine, assistée par IA ou principalement générée par agent. L’objectif n’est pas de calculer un pourcentage d’auteur-machine ; il est de savoir quel régime de responsabilité a été invoqué.

La deuxième partie nommerait la personne qui soutient la contribution et son engagement de maintenance. Elle préciserait la classe d’impact, l’auteur de la classification, la date et la version de politique. Au lieu d’un score opaque, elle examinerait séparément sécurité, intégrité des données, confidentialité, performance, disponibilité, garde des archives liées aux standards et réversibilité.

La troisième partie relierait les preuves aux risques. Plan humain, couverture et stratégie de tests, dépendances, résultats de performance, contrôle de sécurité, migration de données, déploiement progressif et démonstration de retour arrière n’ont pas tous la même pertinence. Une mention « tests réussis » ne suffit pas si les tests sont précisément la raison pour laquelle une lecture humaine a été réduite.

La quatrième partie décrirait la revue réellement effectuée. Quelles surfaces ont été lues ligne par ligne ? Par qui ? Qu’est-ce qui ne l’a pas été ? Si une autre IA a joué le rôle d’adversaire, quel type d’outil a examiné quels fichiers, avec quel contexte et quelles alertes non résolues ? L’IA produit un élément d’analyse ; elle ne devient pas l’autorité de fusion.

Enfin, la fiche nommerait l’approbateur humain, le responsable du déploiement et celui de la maintenance. Elle donnerait les motifs d’escalade vers une revue complète, la période de surveillance, les déclencheurs de retrait et le chemin de correction. Une reclassification ultérieure ajouterait un état sans effacer l’état initial.

Le dispositif doit rester proportionné. Pour une contribution soumise à la revue intégrale actuelle, quelques champs suffisent. La fiche détaillée appartient à l’exception. Une transparence qui ajoute une lourdeur identique à chaque patch recréerait le problème qu’elle prétend résoudre.

Une IA adverse n’est pas un second responsable

Faire relire du code généré par une IA à une autre IA peut être utile. La seconde peut rechercher des chemins inattendus, des dépendances douteuses, des tests manquants ou des incohérences transversales. Elle peut travailler plus longtemps qu’un humain sur des variantes nombreuses.

Le rapport du directeur exécutif donne d’ailleurs un exemple positif distinct : l’assistance de l’IA aurait réduit de plusieurs semaines ou mois à quelques heures le diagnostic de deux problèmes de performance difficiles dans le Datatracker. Une mesure de mitigation a pu être appliquée rapidement et une correction plus profonde a suivi.

Ce fait ne signifie pas que l’IA a causé les incidents. Il ne signifie pas non plus qu’un succès de diagnostic confère une autorité d’approbation. Deux modèles peuvent partager les mêmes angles morts, la même compréhension incomplète de l’architecture ou des hypothèses semblables. Aucun ne répond à l’incident, ne répare les données, ne maintient le logiciel ou n’explique une exception à la communauté.

La revue adverse doit donc avoir un périmètre et un résultat enregistrés. La décision finale reste attribuée à une personne. « Revu par IA » est une indication de méthode, pas un état terminal de gouvernance.

Le logiciel soutient les standards sans décider des standards

La fiche publique de l’équipe Tools la place sous l’IETF Administration LLC et lui confie le développement et l’exploitation des applications qui soutiennent les travaux de l’IETF. Ces outils servent à écrire, discuter et publier les standards. Leur intégrité mérite donc une attention élevée.

Cette importance ne transforme pas l’équipe en détenteur d’une compétence normative.

La séparation est explicite dans le RFC 8711 : l’IETF LLC assure le soutien administratif et les opérations, mais ne possède aucune autorité sur les activités de développement des standards. Le guide de contribution traduit cette limite en pratique lorsqu’il exige qu’une décision de politique communautaire soit résolue avant qu’un changement dépendant de cette décision soit proposé.

Une classification de faible impact ne doit jamais permettre de glisser une décision contestée dans le logiciel. La fiche de revue devrait dire si le changement exécute une règle déjà établie ou suppose un choix qui appartient à un autre organe.

La doctrine de Running-Code Primacy de Heng Lu aide à remettre les éléments dans l’ordre : l’état opérationnel et les preuves vérifiables doivent limiter les récits institutionnels. Ici, cela ne signifie pas que le code en production peut remplacer le processus des standards. Cela signifie qu’un label administratif ne doit pas masquer qui a fait fonctionner quel code, sur quelles preuves et avec quelles conséquences.

Son analyse du problème d’agence dans la gouvernance de l’internet révèle ensuite les incitations. Le contributeur veut faire accepter sa fonction. L’agent veut produire une solution convaincante. Le responsable de file veut réduire l’attente. Le mainteneur peut vouloir finir une revue. L’organisation hérite des conséquences. La fiche ne supprime pas ces intérêts ; elle empêche leur dilution dans le mot « IA ».

La prudence actuelle mérite d’être conservée

Les sources examinées ne montrent ni dérogation cachée, ni incident causé par une contribution d’IA, ni abandon de la lecture intégrale. Elles montrent une institution qui a décrit honnêtement la limite de sa ressource humaine et qui a commencé par améliorer la forme des contributions.

C’est un bon ordre. Le submitter fournit davantage de preuves. Le mainteneur conserve le dernier mot. La personne qui prête son nom conserve une obligation après la fusion. La solution plus radicale reste annoncée comme discussion.

La prochaine règle ne devrait pas se contenter de promettre un « humain dans la boucle ». Cette formule ne dit ni quel humain, ni à quel moment, ni ce qu’il a effectivement inspecté. La fiche de frontière de revue répond à ces questions sans faire de l’IA un coupable abstrait ou un décideur fictif.

IETF Tools cherche à empêcher que la création bon marché de code ne monopolise son attention. La solution sera robuste si elle conserve, en même temps, le coût de la décision chez ceux qui ont le pouvoir de classer, de fusionner et de maintenir.