
Tech • IA • Robotique • Jeu
Les plus grandes frustrations des développeurs vis-à-vis de l’IA en génie logiciel portent sur des tests gonflés, une concentration perturbée, des promesses exagérées, une production à faible valeur, un faible sens de la responsabilité, et le risque de pousser les ingénieurs juniors à livrer plus vite sans apprendre les fondamentaux.
Une plainte récurrente est que le code généré par l’IA peut inonder les projets de tests de bout en bout excessifs, parfois en en modifiant ou en ajoutant des centaines d’un coup. Cela crée des pipelines de CI lents et instables, surtout dans des applications simples qui n’ont pas besoin d’une couverture massive. Le vrai problème n’est pas le test en soi, mais le mauvais jugement sur ce qu’il faut tester et à quel niveau.
L’IA peut générer du code plus vite qu’une personne ne peut l’écrire, mais elle introduit aussi du temps d’attente pendant l’exécution des tâches, l’arrivée des réponses ou l’application des modifications. Cela pousse souvent les développeurs à lancer plusieurs fonctionnalités à la fois, pour finir désorientés entre trois ou quatre fils de travail en parallèle. Pour beaucoup d’ingénieurs, l’IA améliore le débit jusqu’à un certain point; au-delà, elle dégrade la concentration.
La pression d’adopter chaque nouvel agent IA, framework ou flux de travail est devenue en soi une source de frustration. Les outils évoluent si vite que les affirmations tranchées sur une unique “bonne” manière de travailler deviennent souvent obsolètes en quelques semaines. La leçon générale est que les ingénieurs ont peu de chances de prendre du retard simplement parce qu’ils n’utilisent pas immédiatement le dernier workflow à la mode.
Une source majeure de tension est l’écart entre ce que l’IA peut faire aujourd’hui et ce qu’on prétend qu’elle peut faire. Les modèles actuels peuvent aider des développeurs peu expérimentés à produire des logiciels fonctionnels dans des catégories familières, mais on est loin de la conception et de l’exploitation de services résilients à l’échelle de Cloudflare ou Vercel. La différence entre livrer du code et construire des systèmes durables reste considérable.
Une autre plainte fréquente concerne le volume même de texte de faible valeur généré par les outils d’IA. Même lorsqu’on leur demande une réponse courte ou une liste, beaucoup de systèmes renvoient des explications verbeuses, du cadrage et des répétitions qui enfouissent l’information utile. La relecture devient alors un gouffre de temps, les développeurs devant lire des centaines de mots pour extraire une seule phrase exploitable.
Une manière concrète de reprendre la main est de traiter le travail généré par l’IA comme un prototype plutôt que comme le système final. Un schéma efficace consiste à laisser l’IA esquisser une première version, apprendre de sa structure et de ses échecs, puis reconstruire délibérément une seconde version avec une architecture plus claire, moins de tests et moins de code. Dans un exemple, un projet est passé d’environ 100,000 lignes de code à près de 25,000 à 30,000 après cette refonte.
La préoccupation la plus sérieuse à long terme est l’effet sur les développeurs les moins expérimentés. Les équipes peuvent désormais exiger une production rapide des juniors parce que les outils d’IA les font paraître immédiatement productifs, mais cette vitesse peut court-circuiter le lent apprentissage de ce qu’est une bonne ingénierie. Sans temps pour étudier l’architecture, la gestion des dépendances, les cas limites, la stratégie de test et les compromis, les nouveaux développeurs risquent de devenir des opérateurs de prompts plutôt que des ingénieurs.
Même si les capacités de l’IA continuent de progresser, les entreprises ont toujours besoin de personnes capables de raisonner sur les systèmes, de contester les idées faibles et de prendre de bonnes décisions techniques. Le meilleur candidat n’est pas celui qui se contente de transmettre des instructions à un modèle, mais celui qui sait décomposer un problème, choisir les bons tests, façonner les interfaces et expliquer les compromis. L’IA peut relever le niveau minimal de production, mais le discernement reste le vrai facteur différenciant.
L’IA accélère le travail logiciel, mais elle révèle aussi des habitudes fragiles et crée de nouveaux modes d’échec. La vraie ligne de partage n’est plus de savoir s’il faut utiliser l’IA, mais si elle sert à approfondir le jugement d’ingénierie ou à le remplacer.
Poser une question