Technique & data

Développeur : quelles compétences IA acquérir, et dans quel ordre

Écrire du code n'était déjà pas la partie difficile du métier. Un assistant accélère la frappe et déplace l'effort vers la relecture, la vérification et la décision. La compétence qui change tout n'est pas de savoir demander : c'est de savoir refuser ce qui vous est proposé, et de savoir pourquoi.

Mis à jour le 2026-08-20 · lecture 10 min

L'essentiel, avant de commencer

Le code généré est du code d'un inconnu : il se relit comme tel. La vitesse gagnée à l'écriture se perd intégralement si elle est reprise sur la revue.
Un assistant ignore la version exacte de vos bibliothèques : il mélange les API de deux versions majeures sans le signaler, et le résultat compile parfois.
Il propose des noms de paquets qui n'existent pas. Installer sans vérifier qui publie et depuis quand est un risque de chaîne d'approvisionnement, pas une erreur de frappe.
Le point le plus dangereux : ce qui est supprimé sans être mentionné — une clause de condition, un cas limite, une vérification d'autorisation.

Ce que l'IA change vraiment dans le métier aujourd'hui

Des gestes réels, faisables aujourd'hui avec un assistant intégré à l'éditeur ou un assistant conversationnel. Rien de prospectif.

Le code d'échafaudage. Structure d'un module, parseur d'un format connu, script de migration de données, ligne de commande, configuration de tâche planifiée : du code sans difficulté conceptuelle mais long à écrire.
La traduction entre langages et entre bibliothèques. Porter une fonction d'un langage à un autre, passer d'une bibliothèque de requêtes à une autre, convertir un script en tâche automatisée.
Le déchiffrage de code existant. Reprendre un module que personne n'a touché depuis quatre ans, expliquer une expression régulière de deux cents caractères, comprendre une requête SQL imbriquée. C'est le gain le plus sous-estimé.
Les tests fastidieux. Jeux de données, cas limites auxquels on ne pense pas, tests de sérialisation, doublures. À condition de garder la main sur ce que le test vérifie.
Les messages d'erreur opaques. Une trace de pile illisible, une erreur de compilateur générique, un échec de conteneur : le modèle rend les hypothèses probables et le vocabulaire pour chercher.
L'écrit autour du code. Message de commit, description de pull request, journal des modifications, documentation d'une interface, message d'erreur destiné à l'utilisateur.
Les entrées et sorties fastidieuses. Transformation de formats, nettoyage d'un export, requête complexe à partir d'un schéma que vous fournissez.

Ce qui n'a pas changé

Le découpage d'un système, le choix des frontières entre modules, la modélisation des données, la gestion des états et des pannes, la sécurité, et le fait que le code de production est lu bien plus souvent qu'il n'est écrit. Un assistant optimise l'écriture, c'est-à-dire la partie la moins coûteuse du cycle de vie.

Les compétences à acquérir, dans l'ordre

L'ordre compte. Les deux premières décident du risque que vous faites courir à votre employeur ou à vos clients ; les suivantes décident de la qualité de ce que vous livrez.

Savoir ce qui a le droit de sortir du dépôt

À quoi ça sert

Code propriétaire, données de production, jetons d'accès, schémas de base, contenu de fichiers d'environnement : coller un extrait dans un service dont vous ne connaissez pas les conditions revient à publier cet extrait chez un tiers.

Savoir le faire, c'est

Connaître, pour l'outil que vous utilisez, s'il retient les extraits envoyés, s'ils servent à entraîner le service et où c'est écrit. Savoir reconstruire un exemple minimal qui reproduit le problème sans le domaine métier ni les données réelles. Et connaître la conduite à tenir si un secret est parti : la clé est considérée comme compromise, elle est révoquée et remplacée, on ne se contente pas de supprimer le message.

Le piège classique

Le jeu de données « anonymisé » pour tester. Un export de production auquel on a retiré les noms reste un fichier de données personnelles : il ne devient pas anodin parce qu'il sert à déboguer.

Relire du code généré comme le code d'un inconnu, et savoir refuser

À quoi ça sert

C'est la compétence centrale. Ce que vous validez devient votre code, et il sera lu dans deux ans par quelqu'un qui ne saura pas qu'il a été généré. Un code accepté sans être compris est une dette contractée sans être comptabilisée.

Savoir le faire, c'est

Lire le diff ligne à ligne, jamais accepter en bloc ; savoir expliquer chaque ligne à voix haute avant de valider ; repérer ce qui a été modifié en plus de ce qui était demandé — une condition simplifiée, un cas limite supprimé, un contrôle d'autorisation disparu, un paramètre par défaut changé. Et savoir dire non : réécrire à la main plutôt que valider une solution qui fonctionne pour une raison que vous ne comprenez pas.

Le piège classique

La suppression du contournement. Un code « bizarre » est souvent bizarre pour une raison : un bogue d'une dépendance, un cas client, une contrainte de performance. L'assistant le nettoie parce qu'il ne connaît pas cette raison, et la régression revient des mois plus tard sans lien apparent avec le changement.

Donner le contexte technique exact, versions comprises

À quoi ça sert

La cause la plus fréquente de code inutilisable n'est pas la difficulté du problème, c'est la version. Un assistant mélange les API de deux versions majeures d'un même cadriciel, propose une option de configuration retirée depuis longtemps ou une méthode qui n'a jamais existé dans la vôtre.

Savoir le faire, c'est

Fournir d'emblée : langage et version, cadriciel et version majeure, système d'exécution, gestionnaire de paquets, les conventions du dépôt (style, structure, gestion des erreurs), le message d'erreur complet et non résumé, ce que vous avez déjà essayé et ce qui a été écarté. Coller le code réel plutôt que de le décrire. Et indiquer les contraintes non fonctionnelles : volume attendu, latence acceptable, compatibilité à conserver.

Le piège classique

Le prompt de mise en scène — « tu es un développeur senior ». Cela change le ton, pas l'exactitude. Ce qui change le résultat, ce sont les numéros de version et le code existant.

Vérifier toute dépendance proposée avant de l'installer

À quoi ça sert

Un assistant invente des noms de bibliothèques, avec une API complète et un exemple d'utilisation crédible. Des travaux de sécurité publiés ces dernières années décrivent le risque qui en découle : des attaquants enregistrent sur les dépôts publics des noms de paquets fréquemment inventés par les modèles, en pariant sur une installation faite sans contrôle.

Savoir le faire, c'est

Avant toute installation : ouvrir la page du paquet sur le dépôt officiel, vérifier qu'il existe, qui le publie, la date de la dernière publication, le dépôt de code associé et la licence. Vérifier aussi que la fonction citée existe dans la documentation de la version installée, et pas seulement qu'elle a l'air correcte. Et préférer, quand c'est possible, la bibliothèque standard à une dépendance supplémentaire.

Le piège classique

Le paquet qui existe mais sous un nom légèrement différent, ou une version majeure d'écart. L'installation réussit, l'import échoue de façon obscure, et l'on passe une heure à déboguer un problème qui n'était qu'un nom.

Garder la main sur ce que le test vérifie

À quoi ça sert

Un test écrit par la même source que le code ne prouve rien : il constate que le code fait ce qu'il fait. C'est le mécanisme le plus efficace pour se donner l'impression d'être couvert sans l'être.

Savoir le faire, c'est

Écrire vous-même l'énoncé de ce qui doit être vrai — le comportement attendu, les cas limites, les erreurs attendues — et ne déléguer que la mise en forme du test. Vérifier qu'un test échoue avant la correction : un test qui passe des deux côtés ne teste rien. Et refuser catégoriquement le geste le plus courant : modifier l'assertion pour faire passer le test au lieu de corriger le code.

Le piège classique

La doublure qui absorbe tout. L'assistant remplace la dépendance qui pose problème par un simulacre configuré pour répondre exactement ce qu'attend le test : la suite est verte, le comportement réel n'est jamais exercé.

Connaître la géographie des erreurs : là où le code généré casse

À quoi ça sert

Les défauts ne sont pas répartis au hasard. Savoir où regarder en priorité transforme une relecture vague en contrôle rapide et ciblé.

Savoir le faire, c'est

Regarder systématiquement : les frontières de confiance (validation des entrées, contrôle d'accès, requêtes construites par concaténation) ; la concurrence (transactions, verrous, opérations censées être atomiques) ; l'argent et les arrondis (jamais en virgule flottante) ; les dates, fuseaux et changements d'heure ; la pagination et les requêtes en boucle ; la gestion des erreurs — une exception avalée silencieusement est le défaut le plus fréquent du code généré ; et tout ce qui est destructif : migrations, suppressions, écrasements de fichiers.

Le piège classique

Le code non sécurisé mais idiomatique : une requête construite par concaténation, une vérification de certificat désactivée « pour que ça marche en local », des permissions largement ouvertes, un secret écrit en dur dans un exemple. C'est propre, c'est lisible, et cela part en production.

Fixer les règles dans l'équipe, pas seulement pour vous

À quoi ça sert

Le risque n'est pas individuel. Si une seule personne valide sans relire, le dépôt entier hérite du problème, et la revue par les pairs perd sa fonction si le relecteur suppose que l'auteur a compris son propre code.

Savoir le faire, c'est

Un document court et daté : outils autorisés, ce qui ne doit jamais être envoyé, ce qui n'est jamais généré sans relecture spécialisée (authentification, cryptographie, migrations, facturation, droits d'accès), obligation de tests pour tout code généré, et la règle de base : l'auteur d'une pull request répond de chaque ligne, générée ou non. Compléter par de l'outillage qui ne dépend pas de la bonne volonté : analyse statique, détection de secrets, alertes de vulnérabilité sur les dépendances.

Le piège classique

Mesurer la productivité au volume de code produit. Un assistant fait exploser cet indicateur tout en augmentant la quantité à relire, à maintenir et à supprimer. Le code écrit vite n'est pas gratuit : il est payé plus tard, par quelqu'un d'autre.

Ce que l'IA fait mal en développement

C'est la section à lire si vous n'en lisez qu'une. Le point commun de ces erreurs : le code compile, la démonstration fonctionne, et le défaut apparaît ailleurs.

Les API qui n'existent pas dans votre version. Méthode retirée, option de configuration inventée, indicateur de ligne de commande imaginaire : le nom est cohérent avec le reste de la bibliothèque, donc il semble juste.
Les noms de paquets. Bibliothèques inexistantes, ou existantes mais abandonnées, ou homonymes dans un autre écosystème. C'est aussi une porte d'entrée pour des dépendances malveillantes.
La concurrence. Conditions de course, transactions mal délimitées, verrous absents, opérations supposées atomiques qui ne le sont pas. Ce sont les défauts qui ne se voient jamais en test et toujours en production.
La sécurité par défaut. Requêtes concaténées, validation d'entrée absente, contrôle d'autorisation oublié entre deux appels, vérification de certificat désactivée, secret en dur dans l'exemple.
Le contexte du dépôt. Il ne connaît ni votre historique, ni la raison d'un contournement, ni la décision d'architecture prise il y a deux ans. Il propose la solution moyenne d'un projet moyen.
Les modifications non demandées. Reformatage massif, renommage, suppression d'un cas particulier, changement d'une valeur par défaut : noyés dans un diff volumineux, ils passent la revue.
Les affirmations de performance. « Cette version est plus rapide » est produit sans aucune mesure. Une optimisation se prouve avec un profileur, sur vos données.
Le débogage à distance. Sans logs ni trace complète, il propose une cause plausible plutôt que de dire qu'il lui manque une information — et vous partez une heure dans la mauvaise direction.
Dire « je ne sais pas ». Face à une question sans réponse établie, il répond quand même, avec le même aplomb que sur un cas trivial. L'absence de doute exprimé ne signifie rien.

La règle qui résume tout

Faites-lui écrire ce que vous auriez su écrire vous-même. Sur ce que vous ne maîtrisez pas, servez-vous-en pour apprendre et pour chercher dans la documentation, jamais pour livrer : vous n'auriez aucun moyen de voir ce qui cloche.

Ce qu'il est inutile d'apprendre

Le temps d'apprentissage d'un développeur est déjà saturé par l'écosystème lui-même. Ces sujets-là peuvent attendre, voire ne jamais venir.

Les recueils de « prompts pour développeurs ». Une demande efficace, ici, c'est du contexte technique et des numéros de version : c'est la compétence n°3, et elle rend les recueils inutiles.
Entraîner un modèle sur votre base de code. Coûteux, vite obsolète, et rarement le vrai besoin — qui est en général de retrouver une information dans le dépôt. Cela relève de la recherche, pas de l'entraînement.
Essayer chaque nouvel assistant et chaque nouvel éditeur. Les sept compétences ci-dessus se transfèrent ; l'habitude d'une interface, non. Les comparaisons de modèles sur des jeux d'épreuves publics ne prédisent rien de votre base de code.
Le vocabulaire des modèles (jetons, température, fenêtre de contexte, plongements) tant que vous ne construisez pas un produit qui intègre un modèle. Pour consommer un assistant, cela n'améliore rien.
Renoncer à apprendre le langage sous prétexte que l'assistant écrit. La compétence n°2 est une compétence de lecture : elle suppose de connaître le langage mieux que si vous l'écriviez à la main. C'est le contraire d'un raccourci.
Le débat sur la fin du métier. Le temps passé à en discuter en ligne serait mieux investi dans la relecture, l'architecture et les tests — c'est-à-dire dans ce que l'assistant ne fait pas.

Où j'en suis

Sept affirmations. Elles ne se cochent pas au ressenti : soit vous pourriez le démontrer sur une pull request en cours, soit non. Rien n'est enregistré.

Je sais ce que devient un extrait de code envoyé à l'outil que j'utilise, et je peux montrer où c'est écrit.
Je peux expliquer chaque ligne du dernier code généré que j'ai validé.
Mes demandes contiennent les versions exactes et le code réel, pas une description du code.
Je n'installe jamais un paquet proposé sans avoir ouvert sa page sur le dépôt officiel.
J'écris moi-même ce que le test doit vérifier, et je m'assure qu'il échoue avant la correction.
Je relis en priorité les frontières de confiance, la concurrence et tout ce qui est destructif.
L'équipe a une règle écrite sur ce qui n'est jamais généré sans relecture spécialisée.

Lecture : la première détermine le risque juridique et contractuel ; la deuxième détermine tout le reste. Les quatre suivantes décident de la qualité de ce que vous livrez, et la dernière de ce qui se passe quand vous n'êtes pas le seul à utiliser un assistant.

Pour aller plus loin

Trois besoins précis, issus des compétences ci-dessus. Ces liens mènent à une recherche Amazon : ce sont des liens affiliés, ils ne changent pas le prix payé (explication).

Un ouvrage sur la qualité et le remaniement du code

Pour la compétence n°2. Relire du code généré demande un vocabulaire pour dire ce qui ne va pas : responsabilité mal placée, dépendance inutile, effet de bord caché, duplication qui n'en est pas une. Sans ce vocabulaire, une revue se réduit à « ça a l'air bon », qui est exactement le problème.

Voir les livres sur la qualité du code sur Amazon

Un livre de sécurité applicative

Pour la compétence n°6 : injections, contrôle d'accès, gestion des secrets, dépendances. Ce sont précisément les catégories où le code généré est plausible et faux, et où l'erreur ne se manifeste pas au moment de l'écriture. Connaître la liste des défauts classiques rend la relecture rapide au lieu de la rendre pénible.

Voir les livres de sécurité applicative sur Amazon

Un ouvrage sur les tests automatisés

Pour la compétence n°5, si votre couverture repose surtout sur des tests écrits après coup. Savoir ce qu'un test doit affirmer, quand une doublure est légitime et quand elle masque le comportement réel : c'est ce qui empêche une suite verte de vous donner une fausse assurance.

Voir les livres sur les tests sur Amazon

Aucune de ces compétences ne nécessite un achat : elles s'acquièrent sur votre propre base de code. Ces références servent à combler un point précis.

Métiers voisins

Les fiches suivantes reprennent la même structure.

Voir tous les métiers suivis — chef de projet, contrôleur de gestion, et les autres.
Avocat, juriste — le même problème de références inventées, transposé aux textes et à la jurisprudence.