- La GenAI (LLM) améliore la productivité des développeurs grâce à ses capacités de génération et d’assistance au code
- Il existait déjà par le passé des outils promettant du « codage sans code », mais le processus réel d’ingénierie logicielle conserve malgré tout une complexité propre
- Depuis le lancement de ChatGPT, la vitesse d’évolution des outils d’IA est frappante, mais plutôt que de bouleverser radicalement l’ensemble du processus, ils jouent surtout un rôle de raccourci majeur pour certaines étapes de problèmes donnés
Les usages réels des développeurs se divisent en deux grandes catégories
- Bootstrappers
- Utilisent des outils comme Bolt, v0 ou Screenshot-to-code pour créer rapidement un nouveau projet ou un MVP
- À partir d’un design (Figma, etc.) ou même d’un concept sommaire, l’IA génère une base de code initiale complète
- Permettent de produire un prototype fonctionnel en quelques heures ou quelques jours
- Même si le résultat reste imparfait pour la production, cela est très efficace pour valider une idée
- Privilégient la validation rapide et l’itération
- Iterators
- Utilisent Cursor, Cline, Copilot, WindSurf et d’autres outils dans leur flux de développement quotidien
- S’appuient sur l’IA pour l’autocomplétion du code, les refactorings complexes, ainsi que la génération de tests et de documentation
- Délèguent à l’IA les tests complexes, la documentation et le refactoring, tout en contrôlant continuellement les résultats
- L’utilisent comme un « pair programmer » qui participe à la résolution des problèmes
- Le développeur répète le cycle de sélection, correction et amélioration des suggestions de l’IA pour faire évoluer le code vers une version optimale
Le problème des 70 % : la difficulté des « 30 % restants » — le paradoxe de la courbe d’apprentissage de l’IA
- L’IA peut produire rapidement du code jusqu’à environ 70 %, mais les 30 % restants deviennent un frein majeur
- On tombe alors dans un cercle vicieux où corriger un petit bug casse une autre partie du système
- Les non-spécialistes et les développeurs juniors, en particulier, ont tendance à accepter tout le code proposé par l’IA et à provoquer ainsi des problèmes en chaîne
- Ils ont du mal à comprendre pourquoi les modifications suggérées par l’IA créent des problèmes
- Les développeurs seniors expérimentés, eux, identifient rapidement les causes d’un bug, restructurent le code et complètent ce que l’IA a manqué en tenant compte de la sécurité et des performances
- Même en utilisant activement l’IA, ils révisent et refactorisent sans cesse pour obtenir un « code maintenable »
- Si des juniors ou des non-développeurs acceptent sans recul du code généré par l’IA, ils risquent de produire un « house-of-cards code » qui s’effondre facilement en environnement réel
- Le paradoxe de la connaissance
- Les seniors peuvent implémenter rapidement avec l’IA des problèmes qu’ils connaissent déjà
- Les juniors doivent apprendre grâce à l’IA, mais s’ils manquent de bases, ils rencontrent de grandes difficultés lors du débogage et de la validation
Modèles d’utilisation efficaces
- Premier jet par l’IA, puis affinage
- Une fois l’implémentation initiale produite par l’IA, l’humain la relit, la refactorise et la teste lui-même
- On ajoute manuellement la gestion des erreurs et les cas d’exception, et on renforce les tests automatisés ainsi que les revues pour améliorer la fiabilité
- On renforce la modularité, la gestion des erreurs, la définition des types et la conception de l’architecture pour rendre le code maintenable
- Conserver une conversation par unité de travail
- Plutôt que de transmettre un gros contexte d’un seul coup, on utilise des prompts distincts pour de petits problèmes afin d’obtenir des réponses plus ciblées
- On relit et on commit fréquemment les changements, avec des cycles de feedback courts
- Une approche « faire confiance, mais vérifier »
- L’IA rédige un premier jet, mais l’humain prend directement en charge la logique importante, la gestion des erreurs et les questions de sécurité
- Il faut toujours écrire des cas de test et vérifier avec soin les performances, la sécurité et la solidité structurelle
Ce que cela implique pour les développeurs
- Commencer petit
- Tester d’abord l’IA sur des tâches petites, bien définies et au périmètre clair, puis examiner soigneusement le code généré
- Avant de passer à des fonctionnalités plus vastes, il faut être rigoureux sur les tests et la documentation, puis élargir progressivement le périmètre
- Préserver la modularité
- Structurer correctement la base de code pour éviter que le code produit par l’IA ne s’y mélange de manière désordonnée
- Découper fichiers et fonctionnalités en petites unités, et définir clairement les interfaces ainsi que les flux de dépendances
- Faire confiance à l’expérience
- Utiliser l’IA comme copilote, mais fonder la décision finale sur sa propre expérience
- Mieux vaut se méfier des morceaux de code ou des conceptions suspects, et respecter les standards d’ingénierie
L’essor de l’ingénierie logicielle agentique
- Jusqu’ici, les outils d’IA se contentaient surtout de générer du code en réponse à des instructions, mais ils évoluent désormais vers le concept agentic
- Une IA agentique planifie, exécute et vérifie elle-même ses objectifs, en opérant de façon plus autonome
- Claude (Anthropic), Cline et d’autres vont au-delà de la simple autocomplétion, en lançant automatiquement un navigateur et en exécutant des tests
- Le débogage lui aussi change
- Un agent peut détecter de lui-même des problèmes potentiels, exécuter des jeux de tests et même inspecter l’état de l’interface pour proposer des correctifs
- Les outils de demain ne traiteront pas seulement du code
- Ils pourront comprendre et intégrer plusieurs canaux d’entrée, comme des captures d’écran d’UI, des diagrammes ou des conversations vocales
- Dans ce mouvement, le rôle du développeur sera de
- Laisser l’IA travailler de manière créative, tout en veillant à ce qu’elle reste guidée par l’humain et qu’elle opère dans une architecture saine
- Construire une boucle de feedback forte entre l’humain et l’IA
- On peut s’attendre à un modèle de collaboration où l’humain définit le cadre global et les objectifs, tandis que l’agent s’occupe des tâches détaillées
- Comme le dit la formule « le langage de programmation le plus important, c’est l’anglais », la capacité à exprimer des exigences de façon claire et précise en langage naturel devient essentielle
Le retour de l’artisanat logiciel ?
- Grâce à l’IA, les prototypes et les démos peuvent être créés rapidement
- Mais lorsque de vrais utilisateurs commencent à manipuler le logiciel dans des environnements variés et sur des edge cases, les problèmes apparaissent
- Des messages d’erreur incompréhensibles pour l’utilisateur
- Des environnements particuliers qui provoquent des plantages (edge cases)
- Des conceptions qui ignorent complètement l’accessibilité (Accessibility)
- Des problèmes de performance sur les appareils lents
- Les détails d’UI/UX font la différence en matière de qualité
- Pour qu’un produit soit réellement « polished » du point de vue du consommateur, il faut de la minutie et une attention humaine
- Si l’IA réduit le travail répétitif, les développeurs peuvent alors se concentrer sur cette qualité de finition
- Ils peuvent consacrer davantage de temps à l’expérience utilisateur, aux edge cases et à une gestion des erreurs pertinente — des domaines à la fois humains et professionnels
Réflexions complémentaires
- Le processus d’ingénierie logicielle couvre des domaines variés — planification, conception, implémentation, validation, monitoring, maintenance — et aujourd’hui l’IA améliore surtout fortement la partie « écriture du code »
- Par le passé déjà, avec COBOL, Visual Basic ou les plateformes no-code, on a régulièrement tenté de faire en sorte que « même les non-développeurs puissent créer facilement du logiciel », mais dès que la complexité augmentait, des développeurs expérimentés redevenaient indispensables
- Plus les outils LLM font exploser la quantité de code produite, plus les projets complexes risquent d’exiger davantage d’ingénieurs seniors
- Les développeurs expérimentés qui savent utiliser l’IA peuvent encore accroître leur valeur
- En conclusion, les outils d’IA semblent évoluer non pas vers un remplacement complet des développeurs, mais vers un renforcement des développeurs qui disposent d’insight et d’expérience
Réflexions complémentaires (avec les commentaires de Gergely)
- En ingénierie logicielle, la part du codage lui-même n’a jamais été si importante que cela
- Fred Brooks, par exemple, répartissait approximativement le temps de travail logiciel ainsi :
- ⅓ planification
- ⅙ codage
- ¼ tests des composants et du système
- ¼ tests système (de tous les composants, à la main)
- Dans la vision actuelle, le temps consacré au codage (tests inclus) a augmenté, mais la planification, la revue de code, le monitoring et le rollout occupent toujours une part importante
- 20 % planification
- 40 % codage (code + tests)
- 20 % revue de code (le code des autres)
- 20 % préparation production + rollout + petites corrections pendant cette période + monitoring + alertes
- Le processus pour bien construire du logiciel
- 1. What : décider quoi construire
- Cela inclut le brainstorming, le design, les tests utilisateurs et la collaboration avec les product managers et les parties prenantes métier
- Dans une startup, cette étape peut être très courte (« on le construit et on voit la réaction »)
- Dans une entreprise déjà bien établie, décider quoi construire peut prendre plus de temps afin de ne pas déstabiliser les clients existants
- 2. How : planifier comment le construire
- On conçoit concrètement comment implémenter le produit, la fonctionnalité ou le service
- On réfléchit aux impacts architecturaux, aux dépendances et à la stratégie de test
- Une startup peut sauter cette étape et passer directement à l’exécution, mais dans une grande organisation, ignorer la conception en amont peut créer de gros problèmes plus tard
- La plupart des équipes passent malgré tout par une certaine phase de planification à l’aide de Design doc, RFC, ADR, etc.
- 3. Build : implémenter réellement la fonctionnalité
- On écrit la fonctionnalité ou le produit en code et on vérifie que cela fonctionne correctement
- 4. Verify : vérifier
- Avant le déploiement en production, on vérifie soigneusement que le comportement est conforme aux attentes
- Dans les services financiers en particulier, où un dysfonctionnement peut avoir des conséquences graves, le processus de QA est très rigoureux
- 5. Ship it : livrer
- On merge les changements et on les met à disposition des clients
- Les modalités de déploiement en production peuvent varier
- 6. Monitoring and oncall : monitoring et astreinte
- Lorsqu’un problème survient sur le produit, on le détecte immédiatement pour le résoudre
- On mène aussi les actions correctives nécessaires pour éviter qu’un incident identique ne se reproduise
- 7. Maintain : maintenance
- On collecte les retours et plaintes des utilisateurs, puis on décide quels bugs corriger et quelles améliorations prioriser
- Cela inclut aussi le tri des retours qui peuvent être ignorés
- 8. Migrate : migration
- De grandes migrations peuvent devenir nécessaires lorsque le produit change profondément ou que la stack technique évolue
- Aujourd’hui, les outils d’IA aident beaucoup à l’étape « Build », mais il faut aussi s’interroger sur leur utilité dans les 7 autres domaines mentionnés ci-dessus
- Depuis les années 1960, le rêve selon lequel « des non-développeurs pourraient créer des logiciels sans développeurs » perdure
- COBOL, Visual Basic et le no-code en sont des exemples
- Il est possible de créer un site web simple sans coder du tout, mais dès qu’on parle de produits complexes, le travail d’ingénierie reste indispensable
- Plus le niveau d’expression augmente, plus il faut indiquer à l’IA dans le détail « comment cela doit fonctionner », ce qui accroît la complexité
- Plus l’IA génère de code, plus le besoin d’ingénieurs spécialisés capables de le maintenir et de maîtriser l’architecture pourrait en réalité augmenter
- Les développeurs seniors qui apprennent aujourd’hui à travailler avec les LLM voient leur productivité progresser et peuvent apporter davantage de valeur en entreprise
Agents IA : une promesse majeure, mais aussi un « territoire inconnu » en 2025
- Deux ans après le lancement des LLM, de nombreux développeurs ont appris à les utiliser pour le codage et l’ingénierie logicielle
- Les LLM apportent déjà une contribution importante pour le prototypage, le passage vers un langage inconnu, ainsi que la vérification de l’exactitude des résultats et la détection des mauvaises réponses (hallucinations)
- Mais les agents IA n’en sont encore qu’à leurs débuts
- À l’heure actuelle, l’agent largement accessible est surtout Devin, dont le prix élevé de 500 dollars par mois suscite des évaluations mitigées
- Avec l’afflux de capitaux-risque, on peut s’attendre à voir apparaître davantage d’outils d’agents de codage IA
- Les prix devraient eux aussi progressivement baisser
- GitHub Copilot devrait ouvrir au grand public son offre agentique Copilot Workspace en 2025
- /dev/agents, fondé par l’ancien CTO de Stripe, devrait également être lancé
- Les agents IA visent une meilleure précision au prix de réponses plus lentes (processus de « réflexion ») et de coûts plus élevés
- On ignore encore dans quelle mesure cette approche améliorera réellement la précision, et dans quels cas d’ingénierie elle apportera un gain de productivité significatif
Une possible hausse de la demande pour les ingénieurs logiciels expérimentés
- Les ingénieurs logiciels expérimentés (senior et au-delà) pourraient devenir encore plus nécessaires qu’aujourd’hui
- Ils savent mieux manier les outils d’IA, comprennent à quoi ressemble un « excellent résultat » et peuvent donc donner des « instructions » précises
- Lorsqu’ils détectent une génération de code erronée, ils savent à quel moment interrompre le processus pour corriger directement le code source
- Avec l’aide des outils d’IA, bien plus de code sera produit, et davantage de particuliers comme d’entreprises créeront leurs propres solutions
- Mais à mesure que la complexité augmente, il faudra des ingénieurs expérimentés capables de la maîtriser
- Les entreprises technologiques existantes elles aussi pourraient avoir besoin de davantage de profils pour gérer la complexité croissante liée à l’IA
- Les ingénieurs logiciels qui développent leur capacité à travailler avec l’IA peuvent devenir plus productifs et plus précieux
- Comme il faut du temps pour vraiment « apprivoiser » ces outils, il est important d’expérimenter et d’apprendre activement dans un environnement qui évolue rapidement
11 commentaires
C’est vraiment un très bon article.
Je suis tout à fait d’accord avec le dernier paragraphe, « possibilité d’une hausse de la demande pour les ingénieurs logiciels expérimentés ». En somme, on l’utilise bien à la mesure de ce que l’on sait, n’est-ce pas ? ^^
Comme pour Expo 52, dans les domaines qui ont récemment connu de grands changements, même un Claude intelligent ne m’a pas vraiment aidé.
Il me proposait sans cesse du code obsolète ou disparu, au point de plutôt me gêner.
Au final, j’ai l’impression qu’on ne peut vraiment bien utiliser l’IA que si l’on a déjà un œil exercé.
Détail mineur, mais sauf erreur de ma part, /dev/agents n'est pas un agent de codage. Le produit n'est pas encore lancé, mais il se présente comme un « OS pour agents IA ».
Personnellement, je pense et je parie que, dans le futur (ou à moyen terme selon le point de vue), le rôle de codeur va se réduire pour tous les ingénieurs, tandis que le rôle de TPM va prendre de l’ampleur.
Comme Cursor écrit mieux le code, on le lui délèguera, et les humains ne feront sans doute l’essentiel de leur travail qu’à la couche d’abstraction supérieure.
Merci pour le partage. J’ai moi aussi récemment écrit un article sur le sujet, et il présente des similarités. https://www.stdy.blog/can-junior-beat-coding-agent/
Résumé : l’avenir des développeurs à l’ère de l’IA (version optimiste)
?? : plus besoin de développeurs maintenant (version PME de merde)
Mon Dieu, hahahaha
1+ hahaha
MDR 100 points