La nouvelle compétence rare, c’est l’orchestration
Les agents de codage deviennent suffisamment performants pour écrire, tester et modifier des dépôts entiers ; c’est précisément pour cette raison que les équipes ont besoin de davantage de supervision humaine, et non l’inverse. En septembre 2026, la question pratique ne sera plus de savoir si un assistant est capable de créer une fonction ou de corriger un test. Beaucoup en sont capables. La véritable question est de savoir qui définit le travail, qui surveille les raccourcis pris par l’agent, qui interprète les données et qui assume la responsabilité de la modification déployée. Une étude récente sur la supervision humaine des systèmes automatisés dans le développement logiciel apporte une terminologie utile pour décrire cette évolution : les développeurs expérimentés ne se contentent pas d’une simple révision a posteriori. Ils effectuent un contrôle a priori, une co-planification, une surveillance en temps réel et une révision a posteriori.
Ce vocabulaire est important car il remplace une illusion dangereuse par un modèle de travail plus honnête. L’illusion dit : l’agent écrit le code, l’humain approuve. Le modèle réel dit : l’humain prépare un terrain de jeu délimité, transforme une intention vague en contraintes vérifiables, surveille l’exécution, intervient lorsque le plan dévie, puis juge si les preuves sont suffisantes. Ce n’est pas moins de l’ingénierie. C’est une ingénierie orientée vers la direction, l’évaluation et la gouvernance.
Pour Paye ta com, la leçon est concrète. Les outils d’IA peuvent accélérer la production de sites web, d’intégrations, de scripts, de tableaux de bord et de contenu technique. Mais la confiance du client ne découle pas du nombre de lignes générées. Elle vient du fait que quelqu’un comprend le besoin, protège les données, fait des compromis et refuse de publier un résultat simplement parce qu’il semble plausible. L’agent peut être rapide ; l’équipe reste responsable du sens.
Pourquoi la supervision commence avant la première requête
Dans de nombreuses équipes, le mot « supervision » évoque la révision finale : un humain ouvre la pull request, lit le diff et clique sur « approuver ». Cette image arrive trop tard. Lorsqu’un agent travaille au sein d’un véritable dépôt, la supervision commence avant la première invite. Elle commence par la définition du périmètre : quels fichiers peut-il modifier, quelles commandes peut-il exécuter, quelles données ne doit-il jamais lire, quelle branche doit rester protégée, et quel niveau de risque nécessite un arrêt immédiat ? Sans ces règles, l’agent transforme une simple requête en une exploration sans limites.
Le contrôle a priori relève donc de l’architecture contextuelle. Un bon chef de projet ne se contente pas de demander : « Corrige ce bug. » Le responsable fournit le symptôme, le comportement attendu, les fichiers concernés, les tests à exécuter, les contraintes de compatibilité et les zones interdites. Il précise également ce qui ne doit pas changer. Cet aspect est souvent moins visible que le code généré, mais il est déterminant : un agent auquel on confie une mission précise peut être évalué ; un agent doté d’une ambition vague ne peut qu’être l’objet d’un espoir.
Les équipes qui souhaitent utiliser l’IA sans perdre le contrôle doivent formaliser ces limites. Un ticket destiné à un agent doit inclure une définition de la réussite, une définition de l’échec, un budget de modification, une liste des risques et une commande de vérification. Même pour une petite tâche, cette structure évite les surprises. Elle oblige l’humain à énoncer ce qui est connu et réduit la tentation de confondre aisance conversationnelle et accord technique.
Co-planifier plutôt que déléguer dans le vide
La co-planification est le moment où l’humain et l’agent transforment un objectif en stratégie. C’est là que réside une grande partie de la valeur ajoutée. Avant de laisser l’agent modifier le référentiel, l’équipe peut lui demander d’identifier les chemins possibles, les fichiers susceptibles d’être concernés, les migrations requises, les tests à ajouter et les effets secondaires. Le résultat attendu n’est pas encore du code ; il s’agit d’un plan susceptible d’être critiqué.
Cette étape s’apparente à une bonne réunion de conception, mais plus courte et mieux outillée. L’humain recherche les hypothèses cachées : l’agent part-il du principe que le projet utilise une version du framework qu’il n’utilise pas ? Ignore-t-il une contrainte de performance ? Propose-t-il de contourner un module existant au lieu de l’utiliser ? Ajoute-t-il une dépendance pour éviter de comprendre une fonction déjà présente ? Ces erreurs sont moins coûteuses à corriger au stade du plan que lorsqu’elles sont enfouies dans un diff de quinze fichiers.
La co-planification contribue également à préserver les compétences humaines. Le véritable risque lié aux agents ne réside pas seulement dans le fait qu’ils commettent des erreurs ; il réside dans le fait que les développeurs cessent de construire leur propre modèle mental du système. Demander un plan, le remettre en question et le réécrire oblige l’ingénieur à rester l’auteur de la décision. L’agent propose, mais c’est l’humain qui organise. Cette distinction devient essentielle lorsque le code touche à la sécurité, à la facturation, aux données personnelles ou à l’expérience client.
Surveiller pendant l’exécution, pas seulement après
Les agents modernes peuvent enchaîner des actions : lire, modifier, exécuter, corriger et répéter. Cette boucle est puissante, mais elle peut aussi amplifier une hypothèse erronée. Si le premier diagnostic est faux, l’agent peut produire une série cohérente de modifications inutiles. La surveillance en temps réel sert à détecter cette dérive avant qu’elle ne se transforme en une pull request convaincante.
Dans la pratique, la surveillance ne consiste pas à observer chaque caractère généré. Elle consiste à définir des points de contrôle. Après l’analyse initiale, l’agent doit résumer ce qu’il pense avoir compris. Avant une migration, il doit répertorier les données qu’il va modifier. Avant d’ajouter une bibliothèque, il doit justifier pourquoi le code existant n’est pas suffisant. Après l’échec d’un test, il doit préciser s’il corrige le produit ou le test. Ces micro-pauses donnent à l’humain une chance d’intervenir.
La surveillance est également un antidote à une automatisation trop confortable. Plus l’agent semble compétent, plus l’humain risque de baisser la garde au mauvais moment. Pourtant, un système autonome peut produire des actions valides localement mais dangereuses globalement : supprimer un cas limite, affaiblir la validation, masquer une exception, assouplir un test ou répercuter un problème sur l’utilisateur. Le rôle de l’humain est de remarquer quand la trajectoire technique cesse de servir l’intention métier.
La revue finale doit porter sur les preuves, et non sur le style
La révision a posteriori reste essentielle, mais sa nature doit évoluer. Lire le code généré par l’IA comme on lirait celui d’un collègue pressé ne suffit pas toujours. L’agent peut produire une solution grammaticalement correcte, idiomatique et bien commentée, tout en se trompant sur le domaine. La révision doit donc commencer par les preuves : quels tests ont été ajoutés, quels scénarios ont été exécutés, quelles hypothèses restent à vérifier, quelles commandes ont réellement été exécutées et quelles zones n’ont pas été inspectées ?
Un bon diff d’agent devrait s’accompagner d’un journal de décision. Pourquoi cette approche ? Quelles alternatives ont été rejetées ? Quels fichiers ont été lus ? Quels tests échouaient auparavant et réussissent désormais ? Qu’est-ce qui pourrait encore poser problème ? Cette documentation n’est pas de la bureaucratie. Elle permet à l’humain de juger de la qualité du raisonnement au lieu de se contenter d’admirer la rapidité de production.
Les équipes doivent également rejeter les preuves circulaires. Un test généré par le même agent qui a écrit le code est utile, mais ce n’est pas une garantie suffisante. Il peut tester l’implémentation plutôt que le besoin. Il peut ignorer le cas que l’agent n’a pas compris. Pour les modifications importantes, au moins une preuve indépendante est nécessaire : un scénario métier rédigé par un humain, un test de régression existant, une revue de sécurité, une validation manuelle ciblée ou une comparaison avec des données réelles anonymisées.
Mesurer ce que l’agent modifie réellement
Une autre pratique prend de plus en plus d’importance : mesurer la portée réelle du changement. Le nombre de fichiers modifiés ne suffit pas. Une petite modification dans un module d’autorisation peut présenter plus de risques qu’un grand nettoyage de commentaires. Une équipe responsable examine la nature du changement : touche-t-il une limite de sécurité, un format de données, une règle métier, une dépendance externe, des performances critiques ou une expérience utilisateur visible ? Cette classification aide à déterminer quel type de révision est nécessaire.
Les journaux d’exécution sont utiles à cet égard. Ils indiquent si l’agent a bien exécuté les tests qu’il prétendait avoir effectués, s’il a ignoré un échec, s’il a modifié le test plutôt que le comportement, ou s’il a essayé plusieurs stratégies contradictoires avant d’obtenir un résultat satisfaisant. Ces traces ne doivent pas être interprétées comme des aveux parfaits, mais comme des indices. Elles permettent au réviseur de poser des questions plus précises : pourquoi ce fichier a-t-il été ouvert ? Pourquoi cette exception a-t-elle été interceptée ? Pourquoi cette validation a-t-elle disparu ?
Enfin, la mesure doit inclure le temps consacré par les humains. Si une tâche « automatisée » permet d’économiser trente minutes de rédaction mais ajoute deux heures de révision angoissante, elle n’est pas nécessairement rentable. L’objectif n’est pas de maximiser l’activité des agents, mais de maximiser le flux de modifications fiables. Les indicateurs doivent donc prendre en compte les annulations, les bogues après la mise en production, la taille des différences, le temps de révision et la clarté des justifications, et pas seulement le volume de code produit.
Cette approche rend également les compromis plus sereins. Au lieu de débattre de manière abstraite pour savoir si l’IA est « bonne » ou « mauvaise », l’équipe observe quels types de modifications fonctionnent bien, lesquels nécessitent trop de supervision, et dans quels cas l’humain doit rester le seul décideur. L’apprentissage devient empirique, partagé et ajustable. L’équipe peut alors améliorer ses modèles, ses autorisations et ses habitudes de révision en s’appuyant sur les modes de défaillance observés plutôt que sur des slogans, ce qui correspond exactement au type de boucle de rétroaction disciplinée qui rend l’automatisation plus sûre au fil du temps.
Les garde-fous doivent être organisationnels
Le problème ne réside pas uniquement dans les compétences individuelles du développeur qui pilote l’outil. Si chaque personne invente seule des règles de contrôle, l’organisation se retrouve face à une loterie. Certains agents seront cantonnés à des tâches bien délimitées ; d’autres auront accès à des référentiels, à des secrets ou à des environnements de production sans politique claire. La maturité consiste à normaliser un contrôle de qualité.
Une politique minimale doit distinguer les tâches sûres, les tâches sensibles et les tâches interdites. La rédaction d’une première version de documentation ne comporte pas le même risque que la modification d’une règle de paie, d’un flux d’authentification ou d’une migration de base de données. Les tâches sensibles doivent nécessiter une vérification humaine explicite, une preuve de test et une traçabilité concernant la demande, le plan et les commandes exécutées. Les tâches interdites doivent être techniquement bloquées, et non simplement découragées.
Cette gouvernance n’a pas besoin de submerger l’équipe de formulaires. Elle peut s’incarner dans des modèles de tickets, des listes de contrôle pour les pull requests, des autorisations d’accès aux référentiels, des environnements éphémères et des règles d’intégration continue (CI). L’objectif est de faire en sorte que le bon comportement soit la voie la plus facile : agent limité par défaut, justificatifs joints par défaut, décision humaine par défaut.
Conclusion : accélérer sans renoncer
Les agents de codage offrent une véritable opportunité. Ils peuvent réduire le coût des tâches répétitives, explorer des solutions, écrire des tests, expliquer une base de code peu familière et aider une petite équipe à maintenir un rythme autrefois réservé aux grandes organisations. Mais leur valeur dépend de la qualité du pilotage humain. Sans supervision structurée, la rapidité se transforme en dette invisible : plus de code à comprendre, plus de décisions implicites et plus de risques pris en toute confiance.
La bonne attitude n’est donc ni le rejet ni la capitulation. C’est l’orchestration. L’humain définit le périmètre, co-planifie, surveille, exige des preuves et décide. L’agent exécute, propose et accélère. Dans cette division du travail, l’IA renforce l’équipe sans se substituer à son jugement. C’est le modèle le plus réaliste pour des logiciels qui se doivent d’être utiles, sûrs et faciles à maintenir : des machines rapides, mais avec la responsabilité humaine clairement aux commandes.
