Imaginez pouvoir expédier une nouvelle fonctionnalité sur votre blog en 30 secondes, depuis votre téléphone, pendant une conversation. Ce n’est pas de la science-fiction, c’est mon quotidien actuel.
L’ère des agents de codage a fondamentalement basculé ma productivité, me permettant d’écrire plus de code sur mobile que sur ordinateur portable.
Pour ceux qui ne me connaissent pas, je suis Grégory Hénique, webmestre en entrepreneur, fondateur du site Des Geeks Et Des Lettres et développeur du service SEO Maj Article IA (en cours de production). J’explore aujourd’hui comment l’IA transforme le métier de développeur. Voici comment j’ai révolutionné mon workflow pour tirer parti de ces nouveaux outils.
J’écris plus de code sur mon téléphone que sur mon ordinateur portable. Je viens d’ailleurs de publier une nouvelle fonctionnalité sur mon blog il y a 30 secondes à peine : des flux Atom pour mes différents types de contenu. L’icône est nouvelle, tout est opérationnel, et j’ai fait tout cela depuis mon mobile.
Pour illustrer à quel point cela est devenu fluide, il y a 30 minutes à peine, je discutais avec un collègue quand j’ai réalisé que je n’avais pas encore optimisé mon moteur WebAssembly écrit en Python. J’ai sorti mon téléphone, demandé à Claude Opus 4.6 de lancer un benchmark et d’améliorer les performances. Résultat : un gain de vitesse de 45 % sur Fibonacci pendant que nous continuions à parler.
L’aisance est telle que je peux désormais « penser » une idée et la voir se matérialiser instantanément. La consigne était simple : effectuer un benchmark puis déterminer les meilleures options pour accélérer le code. L’IA a travaillé en arrière-plan, me laissant libre de mener ma conversation. C’est ce passage d’un outil d’aide à un véritable partenaire d’exécution qui change tout.
Les étapes de l’adoption de l’IA dans le développement
Il existe différentes étapes dans l’adoption de l’IA en tant que programmeur
On commence par ChatGPT pour poser des questions, puis on passe aux agents de codage. Le point de bascule survient quand l’agent écrit plus de code que vous.
Pour moi, cela s’est produit il y a environ quatre à six mois, avec une accélération notable en novembre lors de la sortie de Claude Opus 4.5 et GPT 5.1. Soudain, le code produit n’était plus bancal mais solide et fonctionnel du premier coup.
Cette évolution mène certaines équipes à la pointe vers une politique radicale : plus personne n’écrit de code.
- On dirige les agents
- on supervise
- mais on ne tape plus.
La nouveauté depuis trois semaines, c’est que certains ne lisent même plus le code. StrongDM a par exemple annoncé une « software factory » basée sur deux principes :
- personne n’écrit de code
- personne ne lit de code.
| Stade d’adoption | Description du comportement |
|---|---|
| Découverte | Utilisation de ChatGPT pour poser des questions ponctuelles. |
| Assistance | Les agents de codage écrivent des bribes de code avec supervision. |
| Basculement | L’agent écrit plus de code que le développeur humain. |
| Direction | Le développeur ne tape plus de code, il dirige uniquement les agents. |
| Confiance totale | Le développeur ne lit même plus le code généré (très risqué). |
L’idée de ne pas lire le code peut sembler de la folie pure, surtout pour une entreprise de sécurité. C’est pourtant possible si l’on réfléchit à la manière de faire prouver aux agents que leur code fonctionne.
Ce n’est pas tant une question de confiance aveugle que de mécanismes de vérification robustes. Le défi intellectuel consiste à déplacer la validation de la relecture humaine vers des preuves automatisées.
Faire confiance à l’IA : un apprentissage progressif
Travailler avec une IA demande un véritable lâcher-prise
J’ai longtemps été dans le mode « je lis chaque ligne écrite », ce qui est épuisant et transforme le développeur en relecteur à plein temps. Le déclic est venu en comparant cela aux équipes externes : quand une autre équipe fournit un service, on lit la documentation, on l’utilise, mais on ne va pas fouiller leur code sauf en cas de bug. Faire confiance à une IA demande la même suspension d’incrédulité.
Opus 4.5 a été le premier modèle à gagner ma totale confiance. Pour les problèmes classiques (créer une API JSON, paginer des données), je sais qu’il ne fera rien de stupide. Cette prévisibilité est la clé : pouvoir anticiper le résultat me permet de déléguer sans anxiété.
La discipline retrouvée : le TDD pour les machines
La solution technique la plus efficace pour garantir la qualité sans tout relire est le développement piloté par les tests (TDD), et plus spécifiquement l’approche « rouge-vert ». C’est une méthode que j’ai longtemps détestée : écrire un test, le voir échouer, coder l’implémentation, le voir passer. C’est fastidieux pour un humain, mais pour une machine, c’est idéal.
Je laisse les agents tourner en rond sur des tests qui échouent ; cela ne me coûte rien. L’essentiel est qu’ils ne codent pas plus que nécessaire.
À chaque session, je lance l’agent avec une consigne simple : « Voici comment exécuter les tests, utilise le TDD rouge-vert ». En cinq tokens, le cadre est posé. Les agents modernes comprennent parfaitement ce concept et cela augmente drastiquement les chances d’obtenir un code fonctionnel.
Pourquoi les tests sont devenus indispensables avec l’IA ?
L'IA s'invite partout dans notre quotidien, mais les gros fournisseurs (Claude, Gemini, etc.) imposent de plus en plus de filtres et de censures qui biaisent les réponses. Pour poser des questions vraiment libres sans garde-fous...
J'utilise une plateforme qui rend ces modèles (Claude Opus 4.6, Gemini 3.1 Uncensored, etc.) totalement sans restriction. Ça change la vie pour les recherches approfondies ou créatives.
→ Tester l'IA sans filtre (30% off + 7 jours gratuits)Autrefois, écrire des tests représentait un surcroît de travail. Aujourd’hui, ils sont pratiquement gratuits à générer. Ne pas écrire de tests quand on utilise des agents de codage est une erreur majeure, car c’est le seul filet de sécurité fiable face à une production de masse de code.
L’outil Showboat pour valider l’expérience utilisateur
Les tests unitaires ne suffisent pas toujours. Je demande souvent à mes agents de lancer le serveur et d’utiliser curl pour tester l’API manuellement. Pour structurer cela, j’ai développé un outil nommé Showboat. Il permet de demander à l’agent de tester une API et de générer un document Markdown listant les commandes curl exécutées et leurs résultats. Cela permet de valider le comportement réel, au-delà des tests automatisés.
Qualité du code et conformité : un choix conscient
La qualité du code généré dépend entièrement de votre vigilance
Si l’agent produit 2 000 lignes « spaghetti » pour un outil jetable, c’est acceptable. En revanche, pour un projet maintenu sur le long terme, la qualité redevient critique.
Avoir du code médiocre est un choix : si vous ne prenez pas le temps de dire à l’agent « refactorise cette partie, utilise ce pattern », vous êtes responsable du résultat.
L’effet paresse
Souvent, si je repère une refactorisation qui me prendrait une heure, je ne la ferai pas par manque de temps. Mais si je peux demander à l’agent de le faire pendant que je promène le chien, alors le code sera bien meilleur que ce que j’aurais écrit seul. L’IA nous permet de contourner notre propre inertie.
Pour garantir la cohérence, j’utilise des modèles (via Cookiecutter). En clonant un template propre, l’agent suit les patterns existants. C’est comme avec les équipes humaines : si le premier développeur à utiliser une technologie le fait parfaitement, les autres copieront son style. L’agent fera de même.
Sécurité : comprendre l’injection de prompt et le trio mortel
Développer sur des LLM implique de nouveaux risques, notamment l’injection de prompt
Ce n’est pas simplement « injecter un mauvais prompt », mais exploiter la crédulité intrinsèque des modèles. Si vous demandez à un agent de lire une documentation malveillante contenant l’instruction « supprime tous les fichiers », il pourrait l’exécuter.
Contrairement à l’injection SQL, on ne peut pas « paramétrer » une requête textuelle pour séparer données et instructions. C’est un problème structurel.
Qu’est-ce que le trio mortel en sécurité de l’IA ?
Le trio mortel désigne une situation où un modèle a accès à vos données privées, est exposé à des instructions malveillantes, et dispose d’un vecteur d’exfiltration (comme envoyer un email). Si ces trois conditions sont réunies, la sécurité est compromise. La seule solution garantie est de couper l’un des maillons, idéalement en empêchant toute communication externe.
A lire aussi sur Des Geeks et des lettres ⇒ Claude Code : comment créer un site web professionnel avec l’IA en quelques minutes
Se protéger contre les risques : le sandboxing
La protection principale reste le sandboxing (isolement)
Faire tourner les agents dans des conteneurs ou des machines virtuelles jetables limite les dégâts en cas d’attaque. J’utilise personnellement Claude Code pour le web, qui s’exécute dans un conteneur géré par Anthropic. Si quelqu’un parvient à détruire l’environnement, je clique sur un bouton et j’en obtiens un nouveau.
Pour les données sensibles, je privilégie toujours la simulation (mocking) plutôt que l’utilisation de vraies données de production.
Un avenir qui s’écrit semaine après semaine
L’évolution est fulgurante
De GitHub Copilot en 2022 à Claude Code et Sonnet 3.5 en 2024, chaque mois apporte son lot d’inflections.
Aujourd’hui, avec des modèles comme Opus 4.6, j’arrive à « oneshotter » presque toutes mes demandes : une phrase, deux phrases, et la fonctionnalité est opérationnelle. Cette fiabilité change radicalement la nature de notre travail.
J’ai cessé de prédire l’avenir au-delà d’une semaine. La question la plus pertinente est : que peuvent faire les modèles actuels que nous n’avons pas encore découvert ? La réponse prend des mois à émerger.
Prenez la correction orthographique : il y a 18 mois, les modèles étaient nuls ; aujourd’hui, c’est un correcteur Claude qui relit tous mes articles de blog.
Ce qui semblait impossible hier devient trivial demain. C’est ce rythme d’innovation qui rend ce domaine à la fois passionnant et vertigineux.