Tous les quelques mois, un titre annonce la fin de la programmation : « l'IA écrira tout le code », « dans deux ans, on n'aura plus besoin de développeurs ». Pendant ce temps, j'utilise l'IA tous les jours, sur des projets clients et sur ce site même, et ma conclusion est différente : l'IA est un outil de travail, pas quelqu'un qui fait le travail à notre place.
Ce n'est pas une position nouvelle. Le compilateur a automatisé l'assembleur, l'IDE a automatisé la mémorisation des API, Stack Overflow a automatisé la recherche de solutions courantes. À chaque fois, le métier a changé, mais il n'a pas disparu : il s'est déplacé vers le haut, vers les problèmes que ces outils ne résolvent pas.
Ce qu'elle fait vraiment bien
Utilisée pour les bonnes tâches, l'IA fait gagner des heures. Dans mon travail quotidien, je l'utilise surtout pour :
- Le code répétitif : DTO, validations, squelettes de composants et de tests.
- Comprendre du code legacy : « explique-moi ce que fait cette fonction de 200 lignes » est un excellent point de départ.
- Les premiers jets : une requête, une regex, un script de migration à relire.
- Les conversions : de JSON vers une interface TypeScript, de CSS vers SCSS, des callbacks vers async/await.
- Une première relecture : erreurs évidentes, noms peu clairs, cas limites oubliés.
Un exemple concret : générer les DTO avec validations pour un formulaire de quinze champs me prenait une vingtaine de minutes de travail mécanique. Avec l'IA, deux minutes suffisent, plus cinq pour relire. C'est le type de gain qu'un outil doit apporter : moins de temps sur le répétitif, plus de temps sur la réflexion.
Où elle s'arrête
La limite n'est pas la qualité du code, souvent bonne. La limite, c'est tout ce qui entoure le code :
- Le contexte : elle ne sait pas pourquoi le client veut cette fonctionnalité, ni quelles contraintes ne sont écrites nulle part.
- Les décisions : entre deux solutions correctes, choisir la bonne pour cette équipe et ce budget.
- La vérification : le code généré a toujours l'air juste, même quand il ne l'est pas.
- La responsabilité : quand quelque chose casse en production, c'est une personne qui en répond, pas un modèle.
Un exemple qui m'est vraiment arrivé. Pour afficher la date d'une commande, l'assistant a proposé ceci :
// Suggested code to show an order date
const date = new Date('2026-10-02');
label.textContent = date.getDate() + '/' + (date.getMonth() + 1);
// Rome: "2/10" — New York: "1/10"Le code compile, les tests locaux passent et en Italie tout fonctionne. Mais une chaîne au format AAAA-MM-JJ est interprétée comme minuit UTC : pour un utilisateur aux États-Unis, la commande apparaît donc à la date de la veille. L'IA ne s'est pas « trompée » au sens strict : elle ne savait pas que le site a des utilisateurs dans plusieurs fuseaux horaires. S'en rendre compte, c'est notre travail.
Une vraie journée de travail : qui fait quoi
Si je regarde une journée type, la répartition des tâches est assez claire :
| Activité | Qui la fait |
|---|---|
| Comprendre ce que le client veut vraiment | Moi |
| Choisir l'architecture et les compromis | Moi, avec l'IA comme interlocutrice |
| Écrire les squelettes de composants, DTO et tests | L'IA, et je relis |
| Analyser une erreur étrange dans les logs | Ensemble |
| Mise en production et responsabilité | Moi |
« Outil » ne veut pas dire « inoffensif »
Dire que l'IA est un outil ne signifie pas que rien ne change. Beaucoup de choses changent : ceux qui faisaient uniquement du travail répétitif sont plus exposés, et les juniors risquent de sauter l'étape où l'on apprend les bases, parce que le code qui fonctionne arrive sans effort.
En même temps, certaines compétences valent plus qu'avant :
- Lire et évaluer du code, pas seulement en écrire.
- Connaître le métier : facturation, santé, logistique, quel que soit le secteur du client.
- Communiquer : transformer une demande floue en exigences précises.
- Vérifier : tests, supervision, relecture critique.
L'utiliser comme un outil : cinq règles
- N'acceptez pas de code que vous ne savez pas expliquer. Si vous ne savez pas dire pourquoi il fonctionne, vous ne saurez pas non plus quand il cessera de fonctionner.
- Donnez du contexte. Version du framework, conventions du projet, contraintes réelles : la qualité de la réponse en dépend.
- Vérifiez avec des tests, surtout les cas limites : valeurs vides,
null, fuseaux horaires, erreurs réseau. - Ne collez pas de données sensibles : clés, mots de passe, données personnelles des clients.
- Mesurez le gain. Si corriger la réponse coûte plus cher que d'écrire le code de zéro, écrivez-le vous-même.
En résumé
Je vois l'IA comme un outil : le plus puissant que nous ayons eu depuis longtemps, mais un outil quand même. Elle automatise le répétitif et accélère les premiers jets ; elle ne connaît pas le contexte, ne prend pas de décisions et n'assume aucune responsabilité. On dit souvent que l'IA ne remplacera pas les développeurs, mais que les développeurs qui l'utilisent bien remplaceront ceux qui l'ignorent : je pense que c'est vrai, à condition d'ajouter que « bien l'utiliser » signifie rester ceux qui comprennent, choisissent et vérifient. J'en parle aussi du point de vue du recrutement dans cet article sur les questions d'entretien à l'ère de l'IA.