Il y a encore peu, le développeur écrivait du code, lisait de la documentation, pestait contre Stack Overflow, puis finissait par comprendre pourquoi “ça ne marche pas”. Aujourd’hui, il demande à une IA de générer une fonction, une API, une regex ou une architecture complète. Et parfois, miracle : ça marche. Enfin… ça compile. Ce qui, dans le monde moderne, semble déjà être devenu une preuve d’intelligence.
L’intelligence artificielle appliquée au développement logiciel est un formidable accélérateur. Elle rédige du code, reformule des tests, explique des erreurs obscures et transforme un ticket mal écrit en début de solution exploitable. Mais elle est aussi une machine à produire du plausible. Et le plausible, en informatique, est souvent le cousin bien habillé du dangereux.
Le code IA : propre, confiant, parfois complètement faux
L’un des grands pièges de l’IA générative, c’est son assurance. Elle ne dit pas “je tente une hypothèse fragile avec trois bouts de ficelle syntaxique”. Elle dit : “Voici une solution.” Avec indentation impeccable, noms de variables rassurants et commentaires pédagogiques. Tout y est. Même l’air sérieux.
Le problème, c’est que l’IA ne comprend pas le besoin comme un développeur expérimenté le ferait. Elle le déduit à partir de la formulation. Elle complète les trous. Elle suppose le contexte. Elle devine les intentions. Et quand elle devine mal, elle ne laisse pas forcément de traces rouges clignotantes. Elle produit simplement un code qui semble convenir.
C’est là que commence le vrai danger : le développeur qui ne sait pas suffisamment ce qu’il demande ne sait pas non plus reconnaître ce qu’il reçoit.
Une IA peut générer une requête SQL vulnérable, une gestion d’authentification bancale, une validation d’entrée décorative ou un chiffrement qui a l’élégance cryptographique d’un cadenas en plastique. Si le développeur n’a pas les bases nécessaires, il validera peut-être la réponse parce qu’elle “a l’air bonne”. Or, en sécurité, “ça a l’air bon” est souvent la phrase prononcée juste avant l’incident.
L’art du prompt : exprimer un besoin n’est pas comprendre un problème
On répète souvent que l’IA dépend de la qualité du prompt. C’est vrai, mais c’est incomplet. Un bon prompt ne se résume pas à écrire poliment “fais-moi une API REST sécurisée”. Encore faut-il savoir ce que signifie “sécurisée”.
Sécurisée contre quoi ? Injection SQL ? Cross-site scripting ? Élévation de privilèges ? Fuite de secrets ? Mauvaise gestion des sessions ? Dépendances vulnérables ? Logs trop bavards ? Permissions trop généreuses ? Tokens éternels façon vampire numérique ?
L’IA répond au besoin exprimé, pas nécessairement au besoin réel. Si le développeur demande “crée-moi une route pour supprimer un utilisateur”, elle peut parfaitement générer une route qui supprime un utilisateur. Mission accomplie. Sauf qu’elle aura peut-être oublié de vérifier que l’appelant est administrateur, que l’utilisateur ciblé existe, que l’action est journalisée, que la suppression respecte les contraintes métier ou que la route ne transforme pas l’application en libre-service de sabotage.
La machine ne néglige pas la sécurité par malveillance. Elle la néglige parce que le besoin formulé ne l’a pas forcée à y penser. Et parce qu’elle n’a pas de responsabilité. Elle ne sera pas en réunion de crise à 23 h 47 avec le RSSI, le DPO et un directeur général qui découvre soudain le mot “post-mortem”.
Le développeur augmenté ne doit pas devenir un développeur anesthésié
L’IA est utile quand elle augmente une compétence. Elle devient risquée quand elle la remplace dans l’esprit de celui qui l’utilise.
Un bon développeur peut utiliser l’IA pour aller plus vite : générer un squelette, comparer plusieurs approches, produire des tests, documenter une fonction, identifier des cas limites. Mais il garde la main. Il relit. Il questionne. Il vérifie. Il sait que le code généré n’est pas une vérité, mais une proposition.
À l’inverse, un développeur qui délègue sans comprendre se retrouve dans une situation étrange : il est responsable d’un code qu’il n’aurait pas su écrire, qu’il ne sait pas toujours expliquer, et qu’il espère ne jamais avoir à déboguer en production. C’est un peu comme construire un pont en demandant à un stagiaire très sûr de lui de choisir les matériaux parce qu’il a “vu passer beaucoup de ponts dans sa vie”.
La compétence reste donc centrale. Plus l’IA devient performante, plus le développeur doit être solide. Non pas pour écrire chaque ligne à la main comme en 2008, mais pour savoir ce qu’il accepte, ce qu’il refuse et ce qu’il doit approfondir.
Le piège de la vitesse
Le grand argument de l’IA, c’est la productivité. Et il est réel. Mais la productivité mal contrôlée accélère aussi les erreurs.
Avant, une faille de sécurité pouvait naître lentement, au prix de plusieurs mauvaises décisions humaines. Aujourd’hui, elle peut être générée en huit secondes, copiée-collée en douze et déployée dans la journée sous le regard attendri d’un manager ravi de voir que “l’équipe a gagné en vélocité”.
La vélocité n’est pas un objectif absolu. Aller vite dans la mauvaise direction reste une performance discutable. Surtout quand la mauvaise direction contient une clé API exposée, un contrôle d’accès absent ou une dépendance connue pour transformer un serveur en buffet ouvert.
L’IA impose donc une nouvelle discipline : ralentir au bon endroit. Aller vite pour produire une première version, oui. Ralentir pour relire, tester, auditer, sécuriser, documenter. L’efficacité ne consiste pas à ne plus penser. Elle consiste à réserver l’effort humain aux endroits où il compte vraiment.
Ce que le développeur doit continuer à savoir
L’arrivée de l’IA ne rend pas les fondamentaux obsolètes. Elle les rend plus indispensables.
Un développeur doit comprendre les principes de sécurité applicative, les modèles d’authentification, la gestion des droits, la validation des entrées, les risques liés aux dépendances, les bases du chiffrement, les logs, les erreurs, les performances, les tests et l’architecture. Rien que ça. Mauvaise nouvelle pour ceux qui espéraient remplacer dix ans d’expérience par une extension VS Code.
Il doit aussi apprendre à dialoguer avec l’IA comme avec un collègue brillant mais distrait. Ne pas se contenter de demander “écris-moi ce code”, mais exiger des hypothèses, des limites, des alternatives, des risques, des tests, des considérations de sécurité. Demander à l’IA de critiquer sa propre réponse. Lui faire produire des scénarios d’abus. Comparer plusieurs solutions. Et surtout, ne jamais confondre explication fluide et vérité technique.
L’IA ne dispense pas de penser, elle punit ceux qui arrêtent
Le paradoxe est là : plus l’IA semble intelligente, plus l’humain doit l’être aussi. Non pas pour rivaliser avec elle sur la vitesse d’écriture, mais pour exercer son jugement.
Le développeur de demain ne sera pas celui qui tape le plus vite. Ce sera celui qui sait formuler correctement un besoin, identifier les angles morts, reconnaître une réponse dangereuse, imposer des contraintes de sécurité et transformer une proposition générée en code fiable.
L’IA est un copilote précieux. Mais un copilote qui peut inventer une route, oublier les freins et expliquer très calmement que tout est conforme. Le développeur reste donc le pilote. Et s’il lâche le volant sous prétexte que la voiture parle bien, il ne faudra pas s’étonner de finir dans le décor avec une documentation parfaitement rédigée.