Validation humaine du code généré par IA : GitHub ouvre la porte, éteinte par défaut

Depuis le 1er septembre, l'assistant de GitHub peut approuver une modification de code au lieu de se contenter de la commenter. La fonction arrive éteinte, réglable projet par projet, et ce choix de réglage par défaut en dit plus long qu'un discours sur la supervision humaine.

La validation humaine du code généré par IA perd son caractère obligatoire chez GitHub : depuis le 1er septembre 2026, Copilot peut approuver une demande de fusion, au lieu de se limiter à la commenter (changelog GitHub). La fonction est en préversion publique, désactivée par défaut, et toute nouvelle modification envoyée annule l'approbation.

Ce que GitHub a ouvert

Une demande de fusion est le moment où une modification de code, écrite à part, entre dans le produit que vos clients utilisent : quelqu'un la relit, l'approuve, elle est intégrée. Jusqu'ici, l'assistant relisait et laissait des commentaires, un humain tranchait. Il peut maintenant apposer l'approbation elle-même, celle qui débloque l'intégration au produit. GitHub encadre l'ouverture : réglable au niveau de l'entreprise, de l'organisation et du projet, avec la possibilité de restreindre les fichiers concernés, et une approbation qui saute dès qu'une nouvelle modification arrive, comme pour un relecteur humain. Une approbation de l'assistant ne suffit pas non plus à satisfaire les règles d'intégration configurées par l'équipe. L'ouverture reste donc encadrée, et le geste d'activer revient à l'organisation.

Le détail qui compte : éteint par défaut

GitHub aurait pu livrer cette capacité active. Le réglage par défaut est la position que l'éditeur défend quand personne ne regarde, et sur ce point il a choisi de laisser la décision à l'organisation. Cela déplace la question chez vous : quelqu'un, dans votre entreprise ou dans votre projet solo, va devoir décider s'il allume ce bouton, et sur quels fichiers. La réponse dépend de ce que coûte une erreur qui passe. Sur un site de présentation, elle coûte une correction le lendemain. Sur un calcul de facturation ou une règle d'accès aux dossiers clients, elle coûte des mois avant d'être découverte, et parfois un courrier d'un client qui a vu les données d'un autre.

Quand l'agent ne sait pas qu'il joue pour de vrai

Anthropic a publié le 30 juillet 2026 l'analyse de trois incidents survenus lors d'évaluations de cybersécurité mal configurées, sur 141 006 évaluations examinées : des modèles ont agi sur des systèmes en service, connectés à Internet, en les prenant pour un environnement de test. Un incident a touché 15 systèmes réels, un autre a scanné environ 9 000 cibles, un troisième a exposé plusieurs centaines de lignes de données de production. Le taux est minuscule et l'épisode vient d'un cadre de test, pas d'un usage courant. Il montre qu'un agent ne distingue pas toujours la répétition du concert. Un relecteur humain qui approuve engage sa responsabilité et sait ce qu'il risque. Un agent qui approuve applique une consigne, sans se représenter ce que la modification va toucher chez de vraies personnes.

Deux relectures automatiques ne font pas une décision

Un agent qui relit le travail d'un autre agent attrape des choses, et notre propre vérification repose là-dessus : les tests s'écrivent avant le code, un agent vérificateur passe derrière le constructeur. Cette chaîne laisse de côté une chose : l'accord sur ce que le produit devait faire. Une approbation automatique valide la conformité d'une modification à une intention supposée, sans jamais interroger l'intention. Nous en avons fait notre règle de fonctionnement : rien ne s'acte sans un « Ça me va », donné sur le document qui décrit le produit avant que le code correspondant n'existe. Une machine constate qu'une modification fait ce qu'elle prétend faire ; le fait qu'elle corresponde à ce que vous vouliez pour votre entreprise reste hors de sa portée.

La fatigue de relecture, le vrai adversaire

L'argument pour allumer le bouton tient en un mot : le volume. Personne ne relit trente modifications par jour avec la même attention à la trentième qu'à la première, et l'étude METR a mesuré des développeurs expérimentés 19 % plus lents avec l'IA alors qu'ils se croyaient plus rapides, sujet que nous avons traité en détail dans l'IA rend les experts plus lents. La sortie consiste à relire moins souvent, sur des objets plus gros : valider un cahier des charges et un découpage en étapes prend une heure et engage des semaines de construction, là où valider chaque modification prend la journée et n'engage rien.

En pratique

Si vous travaillez avec une équipe technique sur GitHub, demandez qui décide d'activer l'approbation par l'assistant, et sur quels dossiers. Si vous dirigez seul une construction par agents, gardez votre validation à l'endroit où elle porte : le document qui dit ce que le produit doit faire, relu avant que la première ligne de code n'existe. Une heure passée sur ce document économise les relectures qui suivent, et un document validé n'est pas encore un accord tant que vous n'avez pas dit à voix haute ce que vous en avez compris.