Votre logiciel garde des interrupteurs oubliés : des agents IA apprennent à les retirer

Il y a dans votre logiciel des interrupteurs que plus personne ne touche. Ils ont servi à activer une fonction, puis on les a oubliés. Un jour, quelqu'un les manipule par erreur, et une partie du programme se remet à faire ce qu'elle ne devrait plus faire. Ce n'est pas une image : le nettoyage est long et sans gloire, alors les équipes le repoussent. Le 22 octobre, deux ingénieurs de DoorDash ont publié les résultats d'une autre approche : des agents d'intelligence artificielle retirent ces interrupteurs à leur place. Leur mesure est assez précise pour qu'on s'y arrête.

Ce qui s'est passé le 22 octobre

DoorDash est une plateforme américaine de livraison de repas. Comme beaucoup d'entreprises numériques, elle confie à ses ingénieurs des outils qui changent le comportement du logiciel sans le réinstaller. Ces outils portent un nom : les feature flags, ou interrupteurs de fonctionnalité. DoorDash les appelle « Dynamic Values ».

Le 22 octobre 2026, deux ingénieurs de l'entreprise ont mis en ligne un document de six pages sur arXiv, une archive publique de travaux scientifiques. Il a été accepté pour la session industrielle d'ICSME 2026, une conférence consacrée à la maintenance des logiciels. Le document décrit un système qui confie le nettoyage à plusieurs agents, avec un contrôle humain au milieu. Il donne aussi les chiffres obtenus sur cinquante nettoyages réels.

Ce qu'est un interrupteur de fonctionnalité

Un interrupteur de fonctionnalité est un réglage placé dans le code. Il permet d'activer ou de désactiver une partie du programme sans redéployer l'application. L'analogie la plus simple est celle du disjoncteur dans un immeuble : on peut couper une aile sans éteindre tout le bâtiment.

Ces interrupteurs rendent de vrais services. Ils permettent de lancer une nouveauté auprès d'une petite partie des utilisateurs, de comparer deux versions, ou d'arrêter une fonction défaillante en quelques secondes. Une fois la nouveauté généralisée, l'interrupteur n'a plus de raison d'être. Pourtant, il reste. Le code qui dépend de lui reste aussi, comme une pièce condamnée dont la porte est toujours là.

Cette accumulation a un nom : la dette technique, comme un entretien qu'on reporte et qui coûte un peu plus cher chaque fois. Un interrupteur oublié n'est pas seulement du code inutile. Il peut réactiver un comportement que l'on croyait disparu. Le document cite un épisode documenté par le régulateur boursier américain : en 2012, un courtier a réutilisé par erreur un interrupteur ancien. Résultat, 460 millions de dollars d'ordres non voulus en 45 minutes.

Pourquoi le nettoyage manuel coûte si cher

Chez DoorDash, le problème est mesurable. En mai 2026, l'entreprise comptait plus de 56 000 interrupteurs répartis dans 623 dépôts de code. Un dépôt est l'espace où une équipe conserve le code et son historique. Environ 2 300 nouveaux interrupteurs sont créés chaque mois.

Parmi eux, 1 659 étaient « périmés » : plus modifiés depuis 90 jours, encore dans le code, jamais archivés et hors liste d'exclusion. DoorDash estime qu'un nettoyage manuel prend entre une et deux heures. Il faut retrouver chaque appel, comprendre la logique, remplacer la condition, puis mettre à jour les tests. Un seul interrupteur peut toucher de 3 à 20 fichiers.

Le calcul est simple. Avec 1 659 nettoyages à une heure, la file représente des milliers d'heures de travail. Et elle grandit plus vite qu'elle ne se vide. Elle n'a jamais la priorité face à une panne. Elle attend.

Comment les agents s'y prennent

Un agent, ici, est un programme qui enchaîne plusieurs actions pour atteindre un objectif. Il ne répond pas une seule fois : il décide des étapes, essaie, vérifie et recommence. DoorDash a construit une chaîne à deux temps, avec un arrêt humain au milieu.

Premier temps : un agent coordinateur, fondé sur Claude Sonnet 4.6, lit le ticket de nettoyage. Il interroge la plateforme qui gère les interrupteurs, parcourt le code, puis prépare un rapport : valeur cible et fichiers concernés. Un ingénieur relit ce rapport et confirme la valeur. Ce point de contrôle est essentiel. Le code peut afficher une valeur par défaut différente de celle réellement active en production. Sans vérification, il figerait la mauvaise valeur.

Deuxième temps : pour chaque interrupteur confirmé, un agent de nettoyage, fondé sur Claude Opus 4.6, travaille dans une copie isolée du code. Cette copie s'appelle un worktree. L'image est celle de nettoyeurs qui reçoivent chacun leur plan d'étage : ils avancent en parallèle sans effacer le travail du voisin. Jusqu'à quatre agents travaillent en même temps sur un même dépôt.

Chaque agent modifie le code, lance les tests, vérifie que 95 % des lignes modifiées sont couvertes par un test, passe un contrôle de style, puis ouvre une demande de fusion. Une demande de fusion, ou pull request, est une proposition de changement soumise à la relecture. Si un contrôle échoue, l'agent corrige et recommence. Un délai maximal d'une heure par agent évite les sessions qui s'emballent.

Ce que les chiffres disent, et ce qu'ils ne disent pas

L'évaluation porte sur les 50 derniers nettoyages réalisés par le système, dans des dépôts écrits en Kotlin, un langage de programmation. Trente-et-un ont été acceptés du premier coup, soit 62 %. Quatorze ont demandé une révision mineure, et cinq ont échoué. Le taux de demandes utilisables atteint donc 90 %.

Les échecs ont une cause précise : la profondeur de la chaîne d'appels. Sur les cinq cas abandonnés, l'agent avait supprimé la majorité du code mort, mais manqué un ou deux maillons dans un enchaînement de fichiers. Ce n'est pas une erreur de compréhension, mais de complétude.

Le coût et le temps mesurent l'intérêt économique. En moyenne, 13,8 minutes et 4,79 dollars par nettoyage. La médiane est plus basse : 12,3 minutes et 3,49 dollars. Les cas complexes montent jusqu'à 40 minutes et 19 dollars. À comparer avec l'estimation interne d'une à deux heures de travail humain.

Les résultats par complexité sont plus instructifs que la moyenne. Les six interrupteurs simples ont tous été traités du premier coup. Les 18 cas moyens atteignent 94 %. Les 26 cas complexes atteignent 85 %. Autrement dit, l'outil est fiable sur le facile et utile sur le difficile, mais ne remplace pas l'ingénieur sur le difficile.

Trois limites empêchent de généraliser. D'abord, l'étude porte sur une seule entreprise, un seul langage et 50 cas. Ensuite, chaque interrupteur n'a été traité qu'une fois : un modèle ne donne pas exactement le même résultat deux fois. Enfin, l'estimation d'une à deux heures relève de l'expérience interne, pas d'une mesure chronométrée.

Sur les 50 demandes générées, les auteurs n'ont observé aucun bogue ni régression introduits par le code modifié. C'est vrai sur cet échantillon, pas une garantie. La différence est importante pour quiconque veut automatiser sans surveillance.

Ce que cela change pour votre entreprise

Vous n'avez probablement pas 56 000 interrupteurs. La leçon reste utile à votre échelle, pour trois raisons.

Premièrement, le nettoyage est un travail de direction, pas seulement d'ingénierie. Si personne ne décide qu'un interrupteur doit disparaître, il reste. Le premier geste n'est pas d'acheter un outil, mais de nommer un responsable et de fixer un rythme.

Deuxièmement, la donnée qui compte est l'état réel en production. Un interrupteur peut être présent dans le code et désactivé depuis un an. Il peut aussi être actif à 100 % alors que le code prévoit encore les deux chemins. Sans cette information, un nettoyage automatique risque de figer la mauvaise valeur. DoorDash le présente comme son choix le plus rentable.

Troisièmement, commencez par le simple. Les interrupteurs à un seul booléen, utilisés dans un ou deux fichiers, sont les plus sûrs à retirer. Les cas à chaînes d'appels profondes demandent encore un ingénieur. Un outil qui promet de tout traiter sans revue n'est pas crédible.

Pour une PME, l'ordre de grandeur compte. Si vous avez vingt interrupteurs et deux heures par mois, un tableur et une revue régulière suffisent. Si vous en avez des centaines, la question devient celle de DoorDash : combien coûte l'attente, et qui la porte ?

Ce qu'il faut retenir

• Un interrupteur de fonctionnalité permet d'activer une partie du logiciel sans le redéployer ; une fois la fonction généralisée, il devient du code inutile et risqué.
• DoorDash comptait plus de 56 000 interrupteurs dans 623 dépôts, dont 1 659 périmés en mai 2026, avec environ 2 300 créations par mois.
• Son système d'agents a produit 45 demandes de fusion utilisables sur 50, en 13,8 minutes et pour 4,79 dollars en moyenne.
• Les cas simples passent à 100 %, les cas complexes à 85 % : l'outil aide, mais ne remplace pas la relecture humaine.
• Le point de contrôle décisif est la valeur réellement active en production, confirmée par un ingénieur avant tout nettoyage.
• Trois prérequis avant d'automatiser : un inventaire à jour, un état de production fiable, et des tests qui bloquent une modification incomplète.