Il y a deux ans, intégrer un assistant IA dans son workflow relevait de l'expérimentation. Aujourd'hui, ne pas le faire est un choix qui se défend, mais qui a un coût. La question n'est plus "faut-il utiliser ces outils ?" mais "comment les utiliser sans se leurrer sur ce qu'ils font vraiment ?" Chez Olympp, nous avons plus de 120 consultants qui travaillent quotidiennement sur des projets à fort enjeu technique. L'IA n'est pas un sujet de conférence chez nous, c'est un sujet d'atelier. Voici ce que nous avons appris.  

Ce que les outils font bien — vraiment bien

Commençons par ce qui est incontestable. La complétion de code répétitif a radicalement changé. Les patterns CRUD, les boilerplates, les tests unitaires sur des fonctions pures, la documentation inline : sur ces tâches, un développeur équipé de Cursor ou Copilot va deux à trois fois plus vite qu'un développeur sans outil. Ce n'est pas une estimation marketing, c'est ce que nous observons sur nos missions. La navigation dans des codebases inconnues est transformée. Arriver sur un projet legacy de 500 000 lignes et comprendre en quelques minutes comment s'articule le flux de données entre deux modules — c'est maintenant possible. Les outils avec une vraie fenêtre de contexte étendue permettent d'interroger une codebase comme on interrogerait un collègue senior qui la connaît par cœur. Le débogage de premier niveau est accéléré. Copier-coller une stack trace, obtenir une hypothèse de cause en 10 secondes : ça marche, et c'est utile pour les erreurs courantes. Ce que ça donne concrètement sur le terrain C’est précisément ce que constate Alexis dans son quotidien de développement, avec le plugin Continue dans IntelliJ, en s’appuyant sur Claude 4.5 Sonnet sur une stack Java / Quarkus et Angular. Sur les modifications sans logique métier, le gain est immédiat. Par exemple : « Modifie cette classe Java pour en faire un record ». Sur ce type de transformation, le résultat est souvent très propre, très rapide, et généralement sans erreur. Même chose sur des refontes ciblées. Lorsqu’il demande : « Extrait la logique de cette fonction Java dans ce composant dans un nouveau service, de sorte à mieux séparer les responsabilités », l’outil est capable de créer la nouvelle classe, déplacer le code et proposer une structure plus lisible. En revanche, le point important reste toujours le même : la génération accélère, mais ne dispense jamais de vérifier que la modification correspond bien à l’intention initiale. Sur la partie front, l’apport est également concret. Exemple : « Dans ce composant MyCard, ajoute un bouton dans le header pour permettre à l'utilisateur de collapse la card et de cacher les détails ». L’IA peut produire le composant, le HTML et le SCSS associés en quelques secondes. Là encore, le premier jet est utile, mais il demande souvent des ajustements manuels et surtout des tests de fonctionnement. C’est d’ailleurs là qu’on touche à la vraie valeur de l’outil : il accélère fortement la mise en place, mais il ne remplace pas la compréhension du comportement réel de l’application. Sur les événements asynchrones, les valeurs par défaut ou certains enchaînements UI, des erreurs apparaissent encore. Et dans ce cas, le bon usage consiste moins à “relancer au hasard” qu’à repartir avec une consigne plus précise, par exemple : « ce bouton ne fonctionne pas correctement, rien ne se passe quand je clique dessus. Aide-moi à comprendre le problème et à corriger ». Dans beaucoup de cas, l’explication fournie et la correction proposée sont pertinentes — à condition qu’un développeur garde la main sur le diagnostic final.  

Ce que les outils ne font pas — et où ça déraille

Le problème avec ces outils, c'est qu'ils sont excellents jusqu'au moment où ils ne le sont plus — et ils ne vous préviennent pas du changement de régime. Ils ne raisonnent pas sur les contraintes métier. Un LLM génère du code syntaxiquement correct et sémantiquement plausible dans un contexte générique. Il ignore votre règle de gestion spécifique, votre contrainte de performance sur ce service particulier, votre convention d'équipe non écrite. Le code suggéré passe les tests… mais pas la revue. Ils créent une fausse confiance sur les sujets qu'ils connaissent mal. C'est le problème inverse de l'humain : quand un développeur ne sait pas, il cherche. Quand un LLM ne sait pas, il propose quelque chose qui ressemble à la bonne réponse. Sur des frameworks récents, des APIs peu documentées ou des architectures peu communes, le taux d'hallucination est significatif. Ils ne remplacent pas l'architecture. Personne ne confierait la conception d'un système distribué à un générateur de texte. Mais la tentation existe de valider trop vite une proposition d'architecture générée par IA parce qu'elle semble cohérente. La cohérence apparente n'est pas la robustesse réelle. Le retour d’Alexis confirme très bien cette limite : l’outil est excellent pour produire vite, restructurer, proposer une base ou débloquer une situation. En revanche, dès qu’on touche au comportement fin de l’application, à l’enchaînement réel des événements ou à la solidité d’une implémentation, le développeur doit reprendre le rôle de filtre critique.  

Notre doctrine chez Olympp

Nous avons stabilisé une approche en trois niveaux. Niveau 1 — Accélération sans friction : tout ce qui est répétitif, documenté, ou standard est délégué sans hésitation à l'outil. On gagne du temps, on l'utilise. Niveau 2 — Assistance avec revue systématique : pour tout ce qui touche à la logique métier, à la sécurité ou à l'intégration avec des systèmes existants, l'IA propose, le développeur décide. La génération n'est pas une validation. Niveau 3 — Domaine humain : architecture système, choix technologiques structurants, trade-offs de performance à long terme. Ici l'IA peut alimenter la réflexion, pas la conduire. La clé, c'est d'être explicite sur dans quel niveau on se trouve. Le glissement de niveau 1 vers niveau 2 sans s'en rendre compte — voilà le vrai risque. Le retour terrain d’Alexis s’inscrit exactement dans cette logique :

• sur une transformation simple, on est clairement en niveau 1 ;
• sur une extraction de logique ou une évolution de composant, on passe rapidement en niveau 2 ;
• et dès qu’il faut comprendre pourquoi “ça ne marche pas”, tester, challenger la solution et arbitrer la bonne correction, on revient sur un terrain pleinement humain.

Ce qui change dans le profil du bon développeur

L'IA déplace la valeur, elle ne la supprime pas. Ce qu'elle dévalue : la capacité à écrire du code sans aide. Ce qu'elle renforce : la capacité à évaluer du code rapidement, à poser les bonnes questions, à détecter les incohérences. Le développeur qui tire le plus de valeur de ces outils n'est pas celui qui les utilise le plus. C'est celui qui sait quand s'en méfier.

Chez Olympp, nous formons nos consultants en ce sens : non pas à "utiliser l'IA", mais à développer un sens critique calibré sur ces outils. C'est une compétence à part entière, qui s'acquiert.

En pratique : notre stack actuelle

• Cursor : pour le développement au quotidien, en mode agent sur les tâches à portée définie
• Claude via API : pour les analyses de codebase et les tâches nécessitant une longue fenêtre de contexte
• GitHub Copilot : dans les environnements où Cursor n'est pas autorisé
• Continue dans IntelliJ : pour intégrer l’assistance IA directement dans l’environnement de développement, avec un usage particulièrement pertinent sur les refontes ciblées, les transformations de code et certaines évolutions front
• Tests automatisés : systématiques, non négociables — l'IA génère plus de code, donc plus de surface à couvrir.

L'outillage n'est pas figé. Ce qui l'est, c'est la rigueur dans la façon de l'utiliser. Olympp accompagne des équipes techniques dans l'intégration de l'IA dans leurs pratiques de développement. Pas en théorie : sur des projets réels, avec des contraintes réelles.