Les IDE “augmentés” à l’IA, j’adore. Ça peut te faire gagner un temps indécent sur les tâches ingrates. Mais il y a un moment précis où ça bascule du côté sombre : quand l’outil commence à écrire dans ton code sans te forcer à regarder un diff. Là, tu n’es plus en train de coder. Tu es en train de laisser un agent pousser des changements dans ton repo… sans la friction qui te protège d’habitude.
Et il y a un deuxième signal qui devrait te faire lever un sourcil tout de suite : quand tu as l’impression que le contexte n’est pas “propre”. Même si, au final, c’est une hallucination de l’IA, le résultat est le même côté dev : tu te retrouves à douter de ce que l’outil a vu, de ce qu’il utilise, et de ce qu’il pourrait exposer.
Donc oui, on va parler de Cursor parce que c’est très visible en ce moment, mais le fond vaut pour tous les IDE/assistants qui touchent au filesystem et au terminal. L’objectif ici est simple : rester “human-in-the-loop” sans perdre la productivité.
Quand l’IA auto-applique des modifications, tu perds le seul truc qui compte : la revue
Un workflow sain, même en solo, a une étape non négociable : tu vois le changement avant qu’il soit “réel”. Dans Git, c’est le diff. Dans une PR, c’est la review. Dans un IDE, c’est au minimum un écran de comparaison, ou un mode “proposer” plutôt qu’“écrire”.
Quand un assistant IA passe en mode “j’applique direct dans le fichier”, tu te retrouves avec un état de code qui a l’air normal, parce que c’est juste du texte dans ton editor. Sauf que tu as zappé la partie où ton cerveau repère les trucs louches : une condition inversée, un import en trop, une modif dans une zone que tu n’avais pas demandé, un renommage partiel, un TODO “temporaire” qui va finir en prod. Le danger, ce n’est pas que l’IA se trompe. C’est que toi tu ne vois plus la tromperie, parce que la friction a disparu.
Le vrai piège, c’est la “normalisation”. Au bout de quelques jours, tu t’habitues au fait que ça écrit. Tu relis moins. Tu testes moins. Tu fais confiance au flux. Et un jour tu te retrouves avec un bug ou une régression sécurité, et tu n’as même pas un moment précis où tu t’es dit « ok, j’accepte ce diff ».
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Le soupçon de mix de contexte : même si c’est “juste” une hallucination, c’est déjà grave
On a vu passer des retours d’utilisateurs où l’agent propose des commandes Git ou des chemins locaux qui ne correspondent pas à leur machine, comme si le contexte venait d’ailleurs. Dans le meilleur des cas, c’est une hallucination un peu flippante, alimentée par des bribes de contexte mal priorisées. Dans le pire, tu imagines la suite : un mélange de conversations, de repos, de clients. Et là on n’est plus sur “l’IA a fait une faute”. On est sur un incident de confidentialité potentiel.
Ce point mérite d’être traité sans drama, mais sans naïveté non plus. En pratique, ce que ça change pour toi, dev, c’est que tu dois construire un workflow où l’outil n’a pas le droit de faire des dégâts, même si son contexte part en vrille. Et ça passe par des garde-fous très terre-à-terre : isolation des workspaces, gestion stricte des secrets, et interdiction des commandes dangereuses en “auto”.
Un détail important : la frontière entre “hallucination” et “fuite” n’aide pas à dormir. Dans les deux cas, l’agent peut te pousser à exécuter une commande qui n’a rien à faire là. Si tu es en mode Auto, que tu as le terminal ouvert, et que tu cliques trop vite, l’incident est déjà en cours.
Revenir à un vrai “human-in-the-loop” dans l’IDE : ce que je veux voir, point
Le premier garde-fou n’est pas Git. C’est ton IDE. Si ton outil propose un mode “preview diff” ou des boutons du style « garder / annuler / appliquer », c’est ce mode-là qui doit être la norme. Pas l’écriture directe. Peu importe la marque : si je ne vois pas clairement ce qui change, je considère que la feature est en bêta permanente.
Je fais aussi une différence nette entre “suggestion de code dans l’éditeur” et “agent qui modifie plusieurs fichiers”. La suggestion inline (style autocomplétion) reste relativement contenue. L’agent multi-fichiers, lui, doit être traité comme un contributeur junior qui a accès à ton repo. Tu ne le laisses pas pousser sur la branche principale, et tu ne le laisses pas “refactorer” sans trace.
Enfin, je veux un comportement clair sur le terminal. Si l’outil peut exécuter des commandes, je veux au minimum une confirmation explicite avant chaque commande, et je coupe tout ce qui ressemble à “auto-run”. Ce n’est pas une question de parano. C’est juste que le terminal est une surface d’attaque, même quand l’attaque vient de toi qui cliques trop vite.
Git comme airbag : si l’IDE enlève la friction, toi tu la remets au bon endroit
Le plus simple pour garder le contrôle, c’est d’arrêter d’imaginer que “c’est juste local”. Dès que l’IA touche à ton code, traite ça comme une mini-PR. Concrètement, je travaille sur une branche jetable dès que je fais une session IA un peu ambitieuse. Une branche qui peut finir à la poubelle sans regret.
Ensuite, je commit plus souvent que d’habitude. Pas des commits propres et narratifs, juste des points de sauvegarde. Ça a deux effets très pratiques. D’abord, tu peux revenir en arrière vite, sans dépendre d’un hypothétique “Undo” de l’IDE. Ensuite, tu peux relire le diff commit par commit, ce qui est infiniment plus facile qu’un gros paquet de changements où tout se mélange.
Et surtout, je “stague” en petits morceaux. Le staging est ton filtre. Si tu fais confiance à un agent pour écrire, mais que tu gardes une main ferme sur ce qui rentre dans l’index Git, tu reprends le contrôle. Quand je vois des gens faire « ok l’agent a modifié 12 fichiers, je commit tout », je sais déjà comment l’histoire finit. Ça finit en debug à 23h, sur un truc bête, que personne n’ose revert parce que “ça a touché partout”.
Si tu ne vois pas le diff dans l’IDE, rends le diff impossible à ignorer
Il y a une approche très basique qui marche bien : tu te forces à passer par Git pour valider que tu as compris. Même si tu as “vu” le code dans l’éditeur, ça n’est pas la même lecture. Le diff te montre la réalité : ce qui a été ajouté, supprimé, déplacé. Et surtout, il te montre les zones où tu n’avais pas demandé de changement.
Un truc que je conseille souvent : quand tu as fini une interaction IA, tu t’arrêtes, tu respires, et tu fais un tour de repo. git diff, puis éventuellement git diff --stat pour voir l’étendue. C’est con, mais ça évite le fameux « ah tiens il a aussi modifié ce fichier de config ».
Si tu bosses en équipe, je préfère même qu’on assume un rituel : “pas de diff, pas de merge”. Un outil qui n’affiche pas le diff n’est pas un argument pour baisser la barre. C’est un argument pour remonter la discipline côté Git.
Des garde-fous automatiques : les tests doivent te protéger de l’agent… et de toi
Le danger d’un agent, ce n’est pas uniquement le code faux. C’est le code “presque juste” qui passe à travers parce que tu as accéléré ton rythme. Les tests, le lint, le type-check, les migrations vérifiées, tout ça devient encore plus important quand le volume de changements augmente.
Je ne suis pas fan des usines à gaz côté hooks, mais un minimum de friction avant un commit est très rentable. Tu n’as pas besoin de tout lancer. Tu veux juste empêcher les régressions débiles : un build cassé, des tests unitaires évidents qui tombent, un formatage incohérent qui pollue le diff.
Voici un exemple volontairement simple de hook pre-commit côté Git (sans dépendance) : il bloque un commit si les tests échouent. Ça ne rend pas l’IA “safe”. Ça rend ton repo moins fragile quand tu vas vite.
#!/usr/bin/env bash
set -euo pipefail
echo "[pre-commit] Running quick checks…"
# Adapte à ton stack
if [ -f package.json ]; then
npm test --silent
fi
if [ -f composer.json ]; then
vendor/bin/phpunit
fi
echo "[pre-commit] OK"Oui, ça peut être trop lent selon le projet. Dans ce cas, déplace le gros des checks en pre-push ou en CI, mais garde au moins un petit filet (lint + typecheck rapide par exemple). L’idée n’est pas de punir, c’est d’éviter de committer n’importe quoi parce qu’un agent a “l’air confiant”.
Séparer les clients, séparer les contextes : l’hygiène qui évite les vrais accidents
Le mix de contexte, qu’il soit réel ou perçu, te rappelle une règle simple : si tu bosses pour plusieurs clients, ton setup doit être compartimenté. Pas “dans ta tête”. Sur la machine.
Dans la vraie vie, ça veut dire des repos clairement séparés, et idéalement des fenêtres/projets d’IDE séparés. Je suis aussi partisan d’éviter les grands “workspaces” fourre-tout où tu as trois clients ouverts, deux environnements, et quinze terminaux. C’est confortable… jusqu’au jour où tu lances une commande au mauvais endroit, ou où l’agent lit des fichiers que tu n’avais pas en tête.
Côté secrets, même logique : arrête de laisser traîner des .env bourrés de clés API sans protection, des tokens dans des fichiers texte, ou des dumps de prod dans ton dossier Téléchargements. Si ton IDE indexe le projet, si l’agent a accès au filesystem, tu veux que le scope reste propre. Un coffre de secrets, des variables d’environnement injectées au runtime, et des permissions minimales, ça n’a rien de “corporate”. C’est juste du bon sens quand des outils automatisés manipulent du contexte.
Interdire par défaut les commandes dangereuses : l’agent ne doit pas avoir les clés du camion
Je vois de plus en plus d’agents proposer (ou tenter) des commandes Git, des scripts de nettoyage, des resets, parfois des trucs qui touchent au système. Et c’est logique : ils essaient d’être utiles. Sauf qu’un agent n’a pas ta prudence. Il n’a pas la mémoire émotionnelle du jour où tu as supprimé un dossier au mauvais endroit.
Mon approche est très simple : tout ce qui est destructif doit rester un geste manuel, conscient, volontaire. Un git reset --hard, un rm -rf, un rebase agressif, un script qui “nettoie” des fichiers, ce n’est pas une suggestion à exécuter. Si l’IDE te permet de laisser l’agent exécuter sans confirmation, coupe ça. Si tu ne peux pas le couper, traite le mode Auto comme un jouet, pas comme un outil de prod.
Et quand tu es sur un projet client, tu peux aller plus loin : un compte utilisateur OS dédié, ou au minimum des permissions qui limitent la casse. Ça dépend des contraintes, mais l’idée reste la même : réduire le blast radius.
En équipe : une PR “agent-generated” doit venir avec des preuves, pas avec de la magie
Le dernier point est social, et il compte énormément. Si l’IA devient un contributeur implicite, il faut l’assumer dans la façon de travailler. Une PR issue d’un agent n’est pas “moins reviewable”. Au contraire, elle doit être plus propre.
Je demande généralement trois choses. D’abord, une description claire de l’intention : ce que l’agent devait faire, et ce qu’il a réellement changé. Ensuite, des tests qui tournent, et si possible un mini protocole de validation quand c’est du comportement fonctionnel. Enfin, une limite assumée : si la PR touche à de l’auth, de la facturation, de la permission, de la crypto, ou de la sécurité au sens large, je veux que ce soit revu comme si c’était du code externe. Pas “ça vient de l’IA donc c’est sûrement bon”.
Et oui, ça veut dire que parfois on dit non. On revert. On refait à la main. Ce n’est pas un échec. C’est juste que le coût d’une régression sur certaines zones est supérieur au gain de vitesse.
Mon avis : les outils vont continuer à accélérer, donc ton workflow doit devenir plus robuste
Le futur proche, ce n’est pas “moins d’agents”. C’est des agents plus présents, plus intégrés, plus tentants à laisser faire. Donc si tu veux en profiter sans te faire piéger, la bonne stratégie n’est pas de tout refuser. C’est de construire un cadre où le contrôle ne dépend pas d’une UI qui peut changer du jour au lendemain.
Git, les tests, la séparation des contextes, la discipline sur le terminal… ce n’est pas sexy, mais c’est ce qui te permet d’utiliser l’IA comme un turbo sans transformer ton repo en roulette russe. Et si ton IDE ne te montre plus de diff avant application, prends ça comme un signal : ce n’est pas à toi de devenir moins exigeant. C’est à ton process de devenir plus solide.
