Le Touilleur Express

  • Accueil
  • A propos de l’auteur
  • A propos du Touilleur Express
Previous

Les outils de génération de code, la couche confort du développeur ?

18 juin, 2025

Il est 9h35, tu sirotes tranquillement ton café devant ton IDE, et là, stupeur : ton collègue junior qui a 30 ans de moins que toi, vient d’ouvrir une pull-request avec 450 lignes, des tests et du code parfaitement fonctionnel. Le tout en 30 minutes. Pourtant tu as bien mis tes lunettes de vieux (tu as plus de 40 ans). Soit il a découvert la méthamphétamine, soit il utilise l’un de ces nouveaux « machins » de génération de code, dont tu as entendu parler à Devoxx France…

Spoiler : c’est la deuxième option (enfin tu l’espères…)

Cursor et Windsurf : les nouveaux meilleurs amis du développeur (ou ses pires ennemis ?)

Commençons par Cursor, un éditeur de code qui intègre directement l’IA pour vous assister dans l’écriture de code. C’est un peu comme avoir un développeur senior qui regarde par-dessus votre épaule, sauf qu’il ne sent pas le café froid et qu’il ne vous juge pas quand vous googlez « comment centrer un div en CSS » pour la 47ème fois. Il est basé sur VSCode, ce qui permet de retrouver très rapidement sa productivité « classique ».

Comment cela se présente concrètement ?

Le mode « Tab » magique : Tu commences à écrire une fonction, et Cursor comprend où tu veux aller. Par exemple :
Tu tapes juste « def calculate_fib » et TAB, et boom, la fonction entière apparaît.

def calculate_fibonacci(n):
    # Cursor génère automatiquement la suite
    if n <= 1:
        return n
    return calculate_fibonacci(n-1) + calculate_fibonacci(n-2)

Le Chat intégré : Un panneau latéral permet de discuter avec l’IA à propos de ton code. « Peux-tu optimiser cette fonction ? » ou « Ajoute des tests unitaires pour cette classe ». C’est comme avoir un développeur senior qui ne dort jamais et qui ne râle jamais quand tu lui poses une question stupide.

La compréhension du contexte : Cursor analyse l’ensemble de ton projet. Si tu as une classe User quelque part, il saura automatiquement proposer des méthodes cohérentes quand tu travailles sur une classe UserService.

Windsurf, de son côté, pousse le concept encore plus loin. C’est l’IDE qui code presque tout seul pendant que vous faites semblant de réfléchir profondément à l’architecture. Un peu comme ces moments où vous fixez l’écran avec un air concentré alors qu’en réalité vous pensez à ce que vous allez manger ce midi. Je le préfère à Cursor, car il s’intègre sous la forme d’un plugin dans les outils de JetBrains. En ce moment je bosse avec PyCharm, mais je peux l’utiliser aussi le soir sur IntelliJ avec du code Scala pour Devoxx France.

Développé par Codeium,il ne se contente pas de compléter ton code. Il peut carrément refactorer des fichiers entiers, naviguer dans ta codebase et comprendre les dépendances entre tes modules.

Les super-pouvoirs de Windsurf :

  1. Mode « Cascade » : Tu peux lui demander de modifier plusieurs fichiers d’un coup. « Ajoute la gestion des erreurs dans tous mes endpoints » et il parcourt ton projet pour appliquer les changements partout où c’est nécessaire.
  2. Compréhension multi-fichiers : Il comprend comment tes fichiers interagissent. Si tu modifies une interface, il peut automatiquement mettre à jour toutes les implémentations.
  3. Refactoring intelligent : « Transforme cette classe monolithique en plusieurs services » – et il le fait vraiment, en respectant les patterns SOLID et tout le tralala.

Jaune devant, marron derrière, le côté obscur de la Force

Soyons cependant honnête quelques secondes : ces outils de développement ne sont pas magiques. Ils sont même très mauvais lorsque vous ne savez pas « prompter » correctement. Et ils ont tendance à se comporter comme vous au bout de quelques jours (ils sentent le café froid, ne sont pas aimables, et ils perdent leurs cheveux aussi…).

Les pièges à éviter :

  1. Le syndrome du « ça compile donc ça marche » : L’IA génère du code qui compile, mais est-ce que ça fait vraiment ce que tu veux ? Spoiler : pas toujours.
  2. La dette technique invisible : Le code généré peut être verbeux ou utiliser des patterns pas optimaux. Il est très facile de générer du code… et il est trop facile de se laisser se faire balader par ces outils (selon ma humble expérience).
  3. La perte de compétences : Si tu ne sais plus coder sans IA, le jour où les serveurs d’OpenAI sont down, tu fais quoi ?
  4. ça rame (et ça peut coûter cher) : c’est parfois poussif, vous attendez 10 minutes pour voir que Windsurf tourne en rond… et n’arrivera jamais à terminer ce refactoring que vous lui avez assigné..
  5. le code introduit des bugs ou des failles de sécurité : restez vigilant sur le code généré, et ne validez jamais rien sans l’avoir relu. Vous aviez cette habitude avec le code de vos collègues… continuez avec le code généré.

Windsurf est « bon » lorsqu’il travaille sur du code existant, que vous limitez le contexte aux fichiers utiles, et que vous arrivez à être assez spécifique sur votre demande. Il est aussi « bon » lorsqu’il est utilisé sur un langage que je connais parfaitement. J’ai eu des sueurs froides sur des bases de code où mon niveau était moins bon. Si vous ne comprenez rien à Scala, je vous rassure : Windsurf non plus 🙂

Cependant, ils évoluent très rapidement. Il y a 2 ans, Copilot était déjà « pas mal » mais nous avons vu que son usage est tombé dans mon entreprise. Les effets « waoouh » du début sont vites passés à la trappe. Le nombre d’utilisateurs de Copilot est tombé rapidement depuis 4 mois chez nous.

Aujourd’hui, bien que Cursor ou Windsurf soient bluffants, il y a encore des progrès à faire…

Il est donc important, voire indispensable de prendre le temps de tester ces outils, pour vous faire votre propre avis. Ne devenez pas le futur stagiaire de l’IA, qui se chargera de vous exploiter pour valider son code svp…

L’intégration continue : quand les robots s’occupent de tout

Nous démarrons un test de Graphite dans mon entreprise (Back Market), dans quelques jours. L’idée étant de voir l’apport d’un outil de revue de code automatisé sur nos différents repos Github.

Nous utilisons déjà Github Actions qui permet d’exécuter des scripts lorsqu’un bout de code est commité, ou lorsque tu merges une branche. Imaginez maintenant l’apport de l’IA sur la gestion des workflows.

Graphite et Diamond : la revue de code sur stéroïdes

Graphite propose Diamond, un outil qui promet de révolutionner la revue de code. Graphite a récemment levé 52 millions de dollars en série B (How AI code review works), et ce n’est pas pour rien.

Graphite : bien plus qu’un simple outil de review

Graphite est une plateforme end-to-end pour développeurs qui aide les équipes sur GitHub à livrer du logiciel de meilleure qualité, plus rapidement. L’entreprise a été fondée en 2020 par d’anciens ingénieurs de Meta, Airbnb et Google qui en avaient marre des workflows GitHub basiques.

Le concept de base ? Les « stacked PRs » (pull requests empilées). Au lieu d’avoir une énorme PR de 2000 lignes que personne ne veut reviewer (avoue, tu l’as déjà fait), tu peux créer une pile de petites PRs interdépendantes.

Diamond : l’IA qui review ton code mieux que ton collègue relou

Diamond est l’outil de revue de code IA de Graphite qui comprend l’ensemble de ta codebase pour fournir des retours immédiats et actionnables sur chaque pull request. Et attention, on ne parle pas d’un bête linter qui te dit « hé, t’as oublié un point-virgule« .

Les super-pouvoirs de Diamond :

  1. Analyse contextuelle : Diamond comprend l’ensemble de la codebase, lui permettant de fournir des retours qui prennent en compte le contexte plus large de l’application (1) Il ne se contente pas de regarder ton diff, il comprend comment ton code s’intègre dans l’ensemble.
  2. Détection de bugs subtils : Diamond peut repérer des problèmes que même des développeurs expérimentés manquent.
    Par exemple :
    • Des conditions logiques inversées dans les if statements
    • Du code spécifique à une plateforme qui ne fonctionnera pas partout
    • Des tokens exposés dans les logs qui créent des risques de sécurité
  3. Règles personnalisables : Les équipes peuvent définir des standards de code spécifiques et des patterns, permettant à Diamond d’appliquer ces directives de manière cohérente à travers le projet (2). Tu peux lui dire « pas de double ternaires » ou « chaque TODO doit avoir un numéro de ticket » et il veillera au grain.
  4. Suggestions de code : Diamond ne se contente pas de critiquer, il propose des solutions. Un clic et le code est corrigé.

Ce qui rend Diamond différent :

Après avoir testé les principaux modèles d’IA, Graphite a découvert que Claude répondait plutôt bien à leurs standards pour la revue de code (3). L’équipe utilise Claude d’Anthropic comme moteur sous-jacent, ce qui explique la qualité des suggestions.

Avec plus de 500 000 pull requests reviewées et moins de 5% de taux de commentaires négatifs, Diamond est un outil qui en plus, s’améliore à chaque fois. Je ne sais pas s’il existe des dispositifs de renforcement, mais j’imagine que oui.

L’intégration de tout ça dans ton workflow

Le workflow moderne (en 2025) avec ces outils ressemble à ça :

  1. Tu codes avec Cursor/Windsurf : L’IA t’aide à écrire le code initial
  2. Tu push sur GitHub : GitHub Actions lance automatiquement tes tests
  3. Tu crées une PR avec Graphite : Tes changements sont découpés en petites PRs digestes
  4. Diamond review ton code : L’IA détecte les bugs et propose des améliorations
  5. Tes collègues humains valident : Ils se concentrent sur la logique métier et l’architecture, pas sur les détails

C’est un peu comme avoir une armée de robots qui préparent le terrain pour que les humains puissent se concentrer sur les décisions importantes.

Cher lecteur, à ce stade, je commence à me demander si mon métier n’est pas en train de devenir « superviseur de robots qui codent ».

Les nouveaux outils comme GitHub Copilot peuvent maintenant :

  • Générer vos tests unitaires (et ils sont souvent meilleurs que les vôtres, avoue-le)
  • Créer des pipelines CI/CD complets
  • Suggérer des optimisations de performance
  • Écrire la documentation (celle que personne ne lit de toute façon)

Rendre facile l’accès à ces outils et sécuriser le code généré

Chez Back Market où je travaille depuis janvier 2024, nous avons lancé un programme qui permet de demander des licences Cursor. C’est ouvert aux développeurs, aux data-analysts, ou aux personnes des équipes plate-formes. Il suffit de faire une demande via Slack à un bot, et nous avons ensuite accès quelques minutes plus tard à l’outil. Le tout est encadré par un contrat, le code est sécurisé et il permet aux développeurs de travailler dans un cadre légal.

Nous utilisons aussi la plate-forme Dust, qui permet de créer ses propres Agents d’IA de façon sécurisée, en s’intégrant avec les données de l’entreprise. Ceci permet de créer un bot qui surveille les releases, d’avoir un outil qui se branche sur BigQuery pour publier sur Slack lorsqu’une anomalie business se produit, de préparer des documents pour des réunions, etc. C’est un outil très pratique qui nous permet de construire nos propres agents.

Le métier de développeur dans 2 ans : toujours vivant ou remplacé par ChatGPT-7 ?

Alors, soyons honnêtes deux minutes. Le Staff Engineer joue parfois le rôle de « Ministre des Affaires Etrangères » pour son groupe. Il va chercher et ramène de l’information. Dans 2 ans, ce rôle sera encore plus crucial car il faudra :

  1. Orchestrer les IA plutôt que coder from scratch
  2. Comprendre le contexte métier (l’IA ne sait toujours pas pourquoi le client veut absolument ce bouton rouge qui clignote)
  3. Debugger les hallucinations de l’IA (quand elle décide que la meilleure façon de trier un tableau est d’invoquer Cthulhu)
  4. Maintenir la cohérence architecturale (parce que 50 micro-services générés automatiquement, c’est pas forcément une bonne idée)

Comme le dit Greg Foster, le CTO de Graphite : « L’IA ne peut pas remplacer complètement la revue de code humaine… Je ne les vois jamais devenir un substitut pour un véritable ingénieur humain qui valide une pull request« .

Je vous conseille aussi la lecture de la lettre d’informations de Morgan Linton : https://www.aipoweredengineering.com/p/ai-powered-engineering-issue-11

Il y a de nombreuses sources et exemples « réels » sur les outils. J’ai découvert Antimetal par exemple. Après le code, il faudra bien se pencher sur la prod et l’observabilité.

Je prédis qu’un certain vendeur de croquettes pour chien va prendre très cher dans les 1 ou 2 ans qui arrivent. La facturation à l’heure est complètement dépassée, surtout lorsque l’on t’explique qu’une heure commencée, c’est une heure facturée…

D’abord l’écriture de code. Ensuite l’intégration continue. Ensuite le déploiement et la gestion de la prod… et enfin l’observabilité de la prod. Je ne vois pas pourquoi nous n’aurions pas une vague d’outils d’ici à quelques mois sur ces marchés.

Le future c’est peut-être l’infrastructure gérée par de l’IA, au service des équipes SRE, avec des outils et de l’analyse générative. A découvrir dans cet article de blog.

Manager ou contributeur individuel, cela a-t-il encore du sens?

L’autonomie technique est le premier palier, qui permet ensuite de se positionner sur 2 voies distinctes. Avec l’IA, ce palier change. Il ne s’agit plus seulement de savoir coder, mais de savoir :

  • Quoi faire coder à l’IA
  • Comment vérifier que ce qu’elle produit a du sens
  • Quand dire « non, là on va le faire à la main »
  • S’assurer qu’elle nous aide mais qu’elle ne nous génère pas plus de stress ou de travail

Je vous parlais dans cet article, des deux voies du métier de développeur :

  1. Manager
  2. Contributeur Individuel

J’en parlerai dans un prochain article, à suivre…

Conclusion : embrasser le chaos (contrôlé)

Les outils de génération de code ne vont pas nous remplacer. Ils vont nous transformer en chefs d’orchestre d’une symphonie de robots. C’est un peu comme passer de « je sais faire du feu avec des silex » à « je sais utiliser un briquet ». L’important reste de ne pas se brûler.

Mon conseil ? Apprenez à utiliser ces outils, mais gardez vos fondamentaux. Parce que le jour où GitHub Copilot décidera de prendre des vacances, il faudra toujours quelqu’un qui sait ce qu’est une boucle for.

Et souvenez-vous : plus tu t’élèveras dans la hiérarchie, moins tu auras le temps de coder et envie de perdre du temps sur des sujets « triviaux ». Alors profites de ces outils pour automatiser les tâches rébarbatives afin de garder du temps pour ce qui compte vraiment : débattre pendant 3 heures sur le nom d’une variable ou sur le meilleur IDE pour coder.

PS : Cet article a été écrit à 73% par un humain et à 27% par une IA. Je vous laisse deviner quelles parties…

Sources :

  • GitHub Copilot – L’assistant IA de GitHub
  • Cursor – L’éditeur qui code avec vous
  • Windsurf – L’IDE du futur (ou du présent ?)
  • Graphite – La plateforme de développement end-to-end
  • Diamond – L’IA de revue de code de Graphite
  • Codeium – La société derrière Windsurf
  • AI Powered Engineering – super petite lettre d’info
  • Article TechCrunch sur la levée de fonds de Graphite – Mars 2025
  • Témoignage Anthropic sur l’utilisation de Claude par Graphite
  • Les nombreuses discussions sur Hacker News sur l’impact de l’IA sur le développement
  • Mon expérience personnelle avec ces outils (et mes cheveux légèrement gris qui en témoignent)
0 no like

Articles similaires:

Redis : le créateur du projet passe de Pivotal à Redis Labs Default ThumbnailJBoss Seam: l'interêt de la conversation Default ThumbnailPrismic.io, gestionnaire de contenu simple et puissant Default ThumbnailPrésentation de Gatling au Paris Scala User Group

Leave a Comment

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image

Chercher

Derniers articles

  • Les outils de génération de code, la couche confort du développeur ?
  • L’instant T où tu poses ta dém…
  • The « Robinson » projection – comprendre son système d’information
  • Réussir son démarrage comme Staff/Principal Engineer dans une nouvelle entreprise
  • Gérer les situations de blocage en tant que Staff Engineer

Commentaires récents

  • Nicolas Martignole dans The « Robinson » projection – comprendre son système d’information
  • Lucas dans The « Robinson » projection – comprendre son système d’information
  • Guillaume dans The « Robinson » projection – comprendre son système d’information
  • Francois Dechery dans The « Robinson » projection – comprendre son système d’information
  • Gaëtan dans The « Robinson » projection – comprendre son système d’information

Les plus lus

  • Les revenus d’un informaticien indépendant en EURL - 89 699 affichage(s)
  • Optional en Java 8 - 71 007 affichage(s)
  • Changer la batterie d’un MacBook Pro de 2011 - 65 612 affichage(s)
  • Quelle est la différence entre volatile et synchronized ? - 65 597 affichage(s)
  • Retour sur la soirée du lundi 12 juillet chez Doctolib - 63 090 affichage(s)
  • Un modèle de Product Backlog et de Sprint Backlog avec Excel - 57 831 affichage(s)
  • Redis, découverte d’un moteur clé-valeur simple et puissant - 51 037 affichage(s)
  • Comment simuler le navigateur de l'iphone avec Firefox ou Safari ? - 45 711 affichage(s)
  • serialVersionUID mythes et légendes - 41 925 affichage(s)
  • Développeur après 31 ans ? Ridé et chauve tu seras - 39 408 affichage(s)

Mots clés

agile ajax Apple architecture barcamp BarCampJavaParis ddd devoxx esb exo flex geek google grails groovy humeur humour independant iphone Java javascript jazoon jboss jboss seam jsf jug Linux mac mule paris jug parisjug pjug play playframework portlet recrutement ria Scala scrum spring Startup usi usi2010 web xebia

Derniers articles

  • Les outils de génération de code, la couche confort du développeur ?

    Il est 9h35, tu sirotes tranquillement ton café devant ton IDE, et

    0 no like

    18 juin, 2025
  • L’instant T où tu poses ta dém…

    Retour d’expérience sur la démission et le moment où vous devez quitter une entreprise.

    7 likes

    24 octobre, 2024
  • The « Robinson » projection – comprendre son système d’information

    Nous sommes en juillet 2022 chez Doctolib. Je travaille sur un projet

    5 likes

    22 octobre, 2024

Mots clés

Apple (32) Architecture (14) Big Data (5) Conference (8) Devoxx (55) Dev Web (37) Doctolib (2) geekevent (1) groovy (2) Innoteria (11) Java (517) Linux (10) Non classé (16) Perso (266) Recrutement (2) Scala (30) scrum (43) Société (3) Staff Engineer (5) Startup (21) Web 2.0 (67)

Le Touilleur Express

Blog par Nicolas Martignole

Contactez-moi : nicolas@touilleur-express.fr

Suivez-moi sur X (Twitter) : @nmartignole

Copyright© 2008 - 2024 Nicolas Martignole | Tous droits réservés
  • A propos de l’auteur
  • A propos du Touilleur Express
  • Reset Password

Le Touilleur Express