Développeur avec l’IA : trois compétences à exercer au-delà de la génération de code

L’IA peut proposer du code, mais savoir quoi lui confier, comment examiner sa réponse et quand reprendre la décision reste un travail d’ingénierie. Dans un billet publié le 2 octobre 2026, GitHub met en avant trois compétences à renforcer : diriger les agents IA, examiner leur production avec esprit critique et garder le jugement technique au centre du workflow. Le billet formule ces priorités ; il ne fournit pas, dans les éléments disponibles ici, de mesure permettant d’affirmer qu’elles garantissent un gain de productivité ou un parcours de carrière particulier.

Pour les rendre utiles au quotidien, on peut les traiter comme trois gestes observables plutôt que comme des qualités abstraites. Il ne s’agit pas de maîtriser un outil précis ni de déléguer davantage à tout prix. L’enjeu est de mieux cadrer le travail, de contrôler ce qui revient et de savoir quelle décision ne peut pas être abandonnée à une sortie plausible.

Le problème : produire plus vite ne dit pas si le travail est mieux maîtrisé

Une réponse convaincante peut masquer une demande mal délimitée, une hypothèse erronée ou un choix technique qui ne convient pas au système concerné. À l’inverse, une proposition incomplète peut être utile si elle révèle une piste que le développeur sait vérifier. Le nombre de lignes générées ne suffit donc pas à juger la qualité du travail : il faut pouvoir relier la demande, le changement et la raison de l’accepter.

Cette distinction aide aussi à ne pas confondre trois activités. Diriger un agent concerne le périmètre de sa tâche. Examiner sa production concerne les éléments qui justifient ou invalident le résultat. Le jugement technique sert enfin à décider si le changement est approprié au contexte, y compris lorsque plusieurs options semblent fonctionner.

Compétence 1 : donner une direction vérifiable à l’agent

Une consigne utile décrit d’abord un résultat attendu et ses limites. « Améliore ce module » laisse à l’agent une grande latitude ; une demande plus exploitable nomme le comportement visé, les fichiers ou composants concernés lorsqu’ils sont connus, les contraintes à préserver et les éléments qui permettront de vérifier le résultat. Le développeur garde ainsi la responsabilité de définir le problème, au lieu de demander à l’outil de le deviner.

Avant de lancer une tâche, on peut expliciter quatre points : l’objectif, le périmètre, les interdits et la preuve attendue. Si l’objectif ou le comportement actuel sont incertains, demander d’abord une analyse sans modification peut aider à rendre ces incertitudes visibles. Cette étape ne garantit pas que l’agent ait compris le dépôt ; elle donne au développeur une occasion de corriger la direction avant qu’un diff ne s’élargisse.

Pour approfondir la gestion des consignes dans la durée, le dossier peut aussi s’appuyer sur cette méthode pour transformer le contexte d’un agent en actif maintenable : versionner et maintenir le contexte d’un agent.

Compétence 2 : examiner la proposition, pas seulement son apparence

Une revue critique commence par une question simple : quelle affirmation le changement est-il censé rendre vraie ? Ensuite, il faut chercher des éléments concrets qui répondent à cette question. Selon le type de modification, cela peut demander de lire le diff, de comparer le comportement attendu aux cas couverts par les tests disponibles, ou de vérifier les hypothèses et les cas limites. La présence d’un test réussi ne démontre pas, à elle seule, que tous les usages pertinents sont couverts.

Il est également utile de demander à l’agent de résumer les fichiers modifiés, les décisions prises et les points qu’il n’a pas pu confirmer. Cette synthèse reste une aide à la revue, pas une preuve indépendante. Le développeur peut alors repérer une modification hors périmètre, une justification qui ne correspond pas au code ou une question laissée ouverte. Pour choisir des contrôles adaptés à un correctif assisté, voir aussi les preuves à examiner avant le merge.

Le geste important n’est pas de chercher une faute à tout prix. C’est de distinguer ce qui est vérifié, ce qui est seulement affirmé et ce qui reste inconnu. Quand la preuve manque, mieux vaut réduire la portée de la conclusion ou demander un complément plutôt que traiter une réponse assurée comme une validation.

Compétence 3 : conserver le jugement technique

Le jugement technique intervient avant et après la génération. Avant, il sert à décider si la tâche est assez claire et assez bornée pour être confiée. Après, il permet de choisir entre accepter, modifier, rejeter ou approfondir la proposition. Cette décision dépend du contexte du projet : un changement local et réversible ne pose pas nécessairement les mêmes questions qu’une modification touchant une interface partagée ou un comportement important.

Pour ne pas laisser l’outil fixer seul les critères de réussite, le développeur peut noter sa propre hypothèse avant de lui demander une solution : quel comportement doit rester vrai ? Qu’est-ce qui rendrait cette approche inacceptable ? Quels éléments du système sont encore mal compris ? Comparer ensuite la réponse à ces critères rend le désaccord plus précis et la revue plus utile.

Un exercice simple pour travailler les trois gestes

Sur une tâche de faible portée, et sans prétendre à un essai déjà réalisé, on peut utiliser cette séquence comme exercice :

• Écrire le résultat attendu, le périmètre et une contrainte à préserver.
• Demander une proposition limitée, puis relever les hypothèses qu’elle implique.
• Lire le diff et vérifier les éléments pertinents au regard du comportement attendu.
• Décider explicitement quoi accepter, quoi corriger et ce qui reste à vérifier.

Après l’exercice, une courte note peut distinguer les éléments confirmés, les hypothèses et les questions en suspens. Ce n’est ni un score de performance ni un protocole de benchmark : c’est une façon de rendre visibles les décisions prises et d’identifier le geste qui mérite d’être mieux travaillé la prochaine fois.

Faire de ces compétences une pratique, pas un slogan

Les trois priorités proposées par GitHub se renforcent mutuellement. Une demande mieux dirigée facilite la revue ; une revue attentive met en lumière les zones où le jugement humain compte ; un jugement clair aide à mieux cadrer la prochaine tâche. La progression ne se mesure donc pas au degré d’autonomie accordé à un agent, mais à la capacité du développeur à expliquer ce qui a été demandé, ce qui a été vérifié et pourquoi la décision finale est défendable.

Pour une équipe, ces gestes peuvent devenir des habitudes de travail : formuler des critères avant la génération, examiner les changements plutôt que leur seule présentation, et rendre visibles les incertitudes. Ils n’éliminent ni les erreurs ni la nécessité de comprendre le système. Ils donnent plutôt un cadre pour utiliser l’assistance sans confondre proposition, preuve et décision technique.