La semaine dernière, j’ai poussé 102 commits sur 5 dépôts en 7 jours. Pas des commits “corriger une faute de frappe” — de vraies fonctionnalités construites avec un développement assisté par AI. Un frontend Next.js headless complet, de zéro. Un pipeline de synchronisation CRM → base de données. Une API Content-as-a-Service. Du tracking GTM. De l’optimisation SEO. Des panneaux d’administration.
Je suis un développeur solo. J’ai eu de l’aide AI pour presque tout.
Ce n’est pas un article sensationnaliste sur le fait que l’AI va remplacer les développeurs. C’est un récit honnête, de première main, de ce qui s’est passé quand j’ai fortement misé sur le développement assisté par AI pendant une semaine entière — ce qui a fonctionné, ce qui m’a surpris, et ce que je continue à me demander.
Les chiffres : ce que le développement assisté par AI a produit en une semaine
Voici ce que dit le git log :
| Jour | Commits | Ce que j’ai construit |
|---|---|---|
| ----- | --------- | ------------------------ |
| Jeudi | 9 | Infrastructure SEO — IndexNow, corrections Bing, optimisation du rendu bloquant |
| Vendredi | 15 | Mise en place d’un frontend Next.js complet, de la spécification de design au commit initial |
| Samedi | 13 | Refonte de la boîte de dialogue de recherche, corrections de scroll iOS, pipeline d’images, SEO |
| Dimanche | 1 | Jour de repos. Un petit commit. |
| Lundi | 17 | Panneau d’administration, intégration newsletter, lancement d’une API Content-as-a-Service |
| Mardi | 22 | Pipeline de contenu AI, système d’aperçu WP, base de connaissances vectorielle |
| Mercredi | 13 | Pipeline complet de synchronisation CRM (Perfex → Supabase → Next.js) + tracking GTM |
Cinq dépôts. Quatre stacks techniques (Next.js, PHP, Python, scripting shell). Zéro coéquipier.
Pour donner du contexte, le développeur moyen pousse 5–10 commits par semaine selon des benchmarks de l’industrie de GitClear et LinearB. D’après mon expérience, le développement assisté par AI a fait passer ma production à environ 10–20x cette base — même si le nombre brut de commits ne raconte qu’une partie de l’histoire.
À quoi ressemble vraiment le développement assisté par AI
Les gens imaginent le codage avec AI comme “vous tapez une invite et du code apparaît”. Ce n’est pas ça. Pas du tout.
C’est plutôt comme d’avoir un collègue extrêmement rapide et extrêmement compétent assis à côté de vous. Un collègue qui ne se fatigue jamais, ne juge jamais vos idées de 2h du matin, et qui peut changer de contexte entre PHP, TypeScript et bash sans cligner des yeux. J’ai testé plusieurs outils pour ce workflow — voici mon comparatif Claude Code vs Cursor→ si vous voulez le détail.
Voici à quoi ressemblait une session typique de développement assisté par AI :
Moi : “Je dois synchroniser les données du personnel de notre CRM Perfex vers Supabase, y compris des champs personnalisés pour les liens vers les réseaux sociaux.”
AI : Lit la documentation de l’API Perfex, lit mon schéma Supabase existant, lit ma couche de données actuelle — puis écrit l’endpoint de synchronisation, la transformation des données, la gestion des erreurs, et met à jour les types. Je relis, j’ajuste, je déploie.
Cette boucle — décrire l’intention, relire la sortie, ajuster, déployer — s’est produite des dizaines de fois par jour. Chaque cycle prenait des minutes au lieu d’heures. C’est la boucle centrale du développement assisté par AI, et une fois qu’on l’a internalisée, on ne revient plus en arrière.
Le multiplicateur de vitesse est réel, mais pas là où vous pensez
Le gain brut de vitesse de codage grâce au développement assisté par AI est peut-être de 3–5x. Impressionnant, mais ce n’est pas le principal.
Le vrai multiplicateur, c’est le changement de contexte. Le mercredi, je suis passé de l’écriture d’un correctif d’API PHP dans le codebase CRM, à la synchronisation de données TypeScript dans Next.js, à la configuration des tags GTM, puis à la mise à jour des composants Tailwind — le tout en une seule matinée. Chacun de ces changements de contexte me coûtait normalement 15–30 minutes de “où j’en étais ?” mental. Avec l’AI qui maintient le contexte, le coût est tombé à presque zéro.
Le deuxième multiplicateur, c’est le courage sur le périmètre. J’ai tenté des choses que j’aurais normalement écartées comme “trop complexe pour ce sprint” :
Cinq patterns que j’ai remarqués dans le développement assisté par AI
En regardant mon historique de commits, cinq patterns ressortent :
1. L’intégration verticale par défaut
Sans AI, j’aurais construit le frontend, puis planifié la synchronisation CRM pour “le sprint suivant”, puis peut-être abordé le pipeline de contenu un jour. Au lieu de ça, j’ai construit toute la stack verticale en une semaine : CRM → API → Database → Frontend → Analytics. Chaque fonctionnalité était complète de bout en bout. Ça reflète la façon dont j’ai construit mon CRM custom avec Next.js et des agents AI→.
2. L’automatisation comme instinct premier
Au lieu de synchroniser manuellement les données CRM avant chaque déploiement, j’ai immédiatement construit un hook de prébuild qui le fait automatiquement. Au lieu de configurer manuellement GTM sur chaque projet, j’ai créé une skill Claude Code réutilisable pour ça. Le développement assisté par AI rend le coût de l’automatisation si faible qu’elle devient le choix par défaut plutôt que les processus manuels.
3. L’architecture la nuit, le polish le jour
Mes commits les plus ambitieux sur le plan architectural ont eu lieu après minuit. Le scaffold complet du projet à 2h. La refonte du formulaire de contact avec un UX guidé par la psychologie à minuit. Le panneau d’administration à 1h. La journée servait à corriger, polir et déployer. J’ai testé cette théorie avec mes données git : 40% de tous les commits ont eu lieu entre 22h et 6h. Avec le développement assisté par AI, on peut être productif même quand son énergie mentale est plus basse.
4. La construction d’outils qui s’additionne
Pendant la semaine, j’ai construit deux skills Claude Code réutilisables — un installateur GTM et un générateur d’Apple Shortcuts. Ce ne sont pas le projet principal, mais ils sont apparus naturellement parce que le développement assisté par AI rend le coût marginal d’empaqueter un workflow en outil réutilisable presque nul. J’utilise la même approche quand je construis des serveurs MCP→ pour mon MCP CMS avec des flows d’agents→.
5. La documentation se fait en ligne
Quand l’AI écrit du code, elle génère aussi de la documentation contextuelle — messages de commit, mises à jour de CLAUDE.md, définitions de types. La documentation n’a plus été une corvée séparée : elle est devenue un sous-produit naturel du workflow de développement assisté par AI.
Les compromis honnêtes du développement assisté par AI
Ce rythme n’est pas gratuit. Voilà ce avec quoi je lutte :
Qualité vs vitesse. Je livre vite, mais est-ce que j’accumule une dette technique que je ne vois pas encore ? Le code généré par AI passe ma revue, mais ma revue à 2h du matin n’est pas ma revue à 10h. J’ai commencé à faire des code reviews “le lendemain matin” sur mes commits de la nuit.
Compréhension vs production. Quand l’AI écrit une transformation de données complexe, je comprends *ce qu’elle fait*. Mais est-ce que je la comprends assez profondément pour la déboguer dans six mois sans aide AI ? Je n’en suis pas sûr. Je prends le temps de lire chaque ligne, mais lire n’est pas la même chose qu’écrire.
Durabilité. 102 commits en 7 jours, 47 heures actives, 40% du travail après 22h. C’est un sprint, pas un marathon. Les outils rendent *possible* de travailler à ce rythme, mais “possible” n’est pas la même chose que “recommandable”.
Risque de dépendance. Si les outils de développement assisté par AI disparaissaient demain, pourrais-je maintenir ce codebase avec la même vélocité ? Absolument pas. J’ai accepté ce compromis parce que je ne pense pas que ces outils vont disparaître — mais il vaut la peine d’être honnête.
Ce que je dirais aux autres développeurs à propos du développement assisté par AI
Si vous n’utilisez pas encore d’outils de codage AI, vous laissez un multiplicateur significatif sur la table. Pas parce que l’AI écrit un code parfait — elle ne le fait pas — mais parce qu’elle supprime la friction qui rend les projets ambitieux “impossibles” pour les développeurs solo.
Voici ma progression recommandée pour adopter le développement assisté par AI :
Les développeurs qui prospèrent dans la prochaine décennie ne seront pas ceux qui codent le plus vite. Ce seront ceux qui peuvent penser en termes de systèmes pendant que l’AI gère l’implémentation — et qui savent quand ralentir et réfléchir soigneusement, malgré le fait qu’un outil rende “aller vite” si facile.
Mettre la semaine en perspective
J’ai construit ce qui serait traditionnellement la production mensuelle d’une petite équipe. Une migration de site web complète, une intégration CRM, une plateforme API, et plusieurs outils open-source — en sept jours.
Mais la chose la plus précieuse que j’ai livrée n’était pas du code. C’était la prise de conscience que le goulot d’étranglement a changé. Ce n’est plus “est-ce que je peux construire ça ?” C’est “est-ce que je devrais construire ça ?” et “est-ce que je construis la bonne chose ?”
Le développement assisté par AI n’a pas changé ce qui est difficile dans l’ingénierie logicielle. Il a juste déplacé la partie difficile.