Comment j'utilise l'IA en tant que développeuse full-stack : ma vraie pile d'automatisation

On me pose une version de la même question : « tu construis des sites et des solutions IA — donc quelle part de ton propre travail l'IA fait-elle réellement ? » La réponse honnête est à plusieurs niveaux. L'IA écrit une grande partie du premier jet de mon code. Elle ne prend aucune décision de jugement. Elle fait tourner des pipelines entiers dans ce projet sans supervision. Elle ne touche jamais la production sans qu'un humain ait d'abord lu le diff. Voici la pile réelle, pas la version marketing.

1. Code : pair programming, pas pilote automatique

L'essentiel de mon usage quotidien de l'IA, c'est Claude Code assis à côté de moi dans le terminal, directement dans ce dépôt. Je décris un composant, un bug, un refactoring à travers les sept dossiers de langue sous src/app, et il rédige le changement. Je lis chaque diff avant qu'il n'atterrisse — de la même façon que je relirais la PR d'un junior. L'IA est très bonne pour « appliquer ce pattern de façon cohérente à 40 fichiers » et nettement moins bonne pour « décider si ce pattern devrait exister ». Je garde donc ce deuxième métier.

Les gains concrets : construire une fois une nouvelle page factory et laisser l'IA en câbler chaque variante de locale, écrire le premier jet d'une suite Vitest pour une nouvelle fonction lib, traduire une stack trace en une cause racine en clair avant que j'aille creuser moi-même, et rédiger des messages de commit à partir d'un diff pour ne pas fixer un curseur vide.

2. Pipelines de contenu et i18n qui tournent sans moi

Ce site livre chaque article de blog en jusqu'à sept langues : en, ua, de, fr, es, it, tr. J'écris les versions anglaise et ukrainienne à la main — cette partie reste la mienne, parce que le ton et la précision technique comptent et que je ne veux pas d'une voix traduite par machine comme la mienne. Les langues restantes sont remplies par des scripts dans scripts/ qui parcourent l'arbre de contenu localisé et appellent une API de traduction pour tout champ sans locale, mettent en cache le résultat pour que les relances ne repaient pas des chaînes que j'ai déjà, et échouent bruyamment au lieu d'écrire silencieusement une chaîne vide dans une page.

Le même instinct d'automatisation se retrouve hors du blog : sitemap.ts régénère chaque route sur chaque locale au moment du build au lieu que je maintienne une liste à la main, le flux RSS et les fichiers llms.txt / llms-full.txt sont dérivés des mêmes données d'articles, donc ils ne peuvent pas dériver de ce qui est réellement publié, et la CI fait tourner tout le passage de tests et de lint à chaque push avant que quoi que ce soit n'atteigne le workflow de déploiement nextjs.yml.

3. L'IA à l'intérieur du produit, pas seulement autour

L'autre moitié de « l'IA dans mon workflow », c'est ce que je livre pour le GEO — generative engine optimization, rendre un site lisible pour un LLM de la même façon que le SEO le rend lisible pour un crawler de recherche. Concrètement : llms.txt et llms-full.txt décrivent ce site dans un format qu'un agent peut parser directement, des données structurées JSON-LD sur les pages de services et de blog pour qu'un modèle extraie des faits au lieu de deviner à partir de la prose, et un composant de balisage de schéma qui reste synchronisé avec le contenu réel de la page au lieu d'un bloc statique que quelqu'un a oublié de mettre à jour.

C'est la frontière qui m'intéresse vraiment : l'IA qui m'aide à construire le site est invisible pour une visiteuse. L'IA qui aide le site lui-même à être compris par d'autres IA est une fonctionnalité que je construis et teste explicitement — il y a une suite Vitest dédiée pour les helpers de flux GEO, précisément pour que ça ne pourrisse pas en silence comme le fait finalement toute intégration non testée.

4. Où je garde le siège humain

Rien de tout cela ne signifie que l'IA décide ce qui est livré. Elle ne choisit pas l'architecture de l'information, elle ne choisit pas quelles pages de services existent, elle ne décide pas qu'un formulaire de contact a besoin d'une règle de validation de plus au lieu de trois champs en moins — ce jugement est le vrai travail, et c'est exactement ce pour quoi les clients paient quand ils embauchent une développeuse plutôt qu'un générateur. L'IA rédige ; je merge. L'IA traduit ; j'écris la source. L'IA propose un refactoring ; je décide si l'abstraction mérite sa place, en suivant la même discipline qui consiste à ne pas ajouter de structure dont la base de code n'a pas encore besoin.

Si vous essayez de comprendre où l'IA fait réellement gagner du temps dans un produit réel — par opposition à où elle ne fait que déplacer la charge de relecture —, c'est généralement la bonne question à poser avant d'automatiser quoi que ce soit : quelle décision est-ce que je retire réellement à un humain, et suis-je à l'aise avec le fait que cette décision soit prise par un script ?

Vous voulez ça pour votre projet ?

Je construis aussi ce type de workflow assisté par IA et centré sur l'automatisation dans les projets clients — des déploiements verrouillés par CI à une structure de contenu prête pour le GEO. Écrivez via le formulaire de contact et dites-moi quelle partie de votre processus vous mange encore la semaine.