Mon graphique de contributions GitHub de 2025 donne l’impression d’avoir été produit par deux développeurs différents. La première moitié de l’année est presque vide. La seconde affiche plus de 4 000 commits.
Je n’avais pas soudainement plus de temps libre. Je continuais à concilier un emploi à temps plein et des side projects. Ce qui avait changé, c’était la quantité de friction entre une idée et une version fonctionnelle : j’avais commencé à utiliser les outils de coding assisté par AI beaucoup plus sérieusement.
Il faut cependant être précis avec ce chiffre. Le nombre de commits n’est pas, à lui seul, une mesure de productivité. Quatre mille commits ne prouvent ni quatre mille améliorations utiles ni une bonne qualité de code. En revanche, le graphique montre bien un changement réel dans mon rythme de travail : je construisais, j’itérais et je livrais des versions fonctionnelles beaucoup plus régulièrement qu’avant.
Le vrai goulot d’étranglement était l’énergie de démarrage
Dans mes side projects, je retrouvais souvent le même problème : la première version utile se trouve derrière beaucoup de travail routinier. Routing, validation, scripts, tests, configuration et nettoyage peuvent consommer l’élan avant même que je sache si une idée mérite d’être poursuivie.
Je reportais autrefois des expériences quand le premier résultat semblait demander plusieurs soirées de setup. Les outils de coding assisté par AI n’ont pas supprimé ce travail, mais ils ont réduit le coût du premier passage et raccourci le chemin vers une version testable.
Le principal gain n’était donc pas de taper plus vite. C’était de réduire l’énergie d’activation : davantage d’idées atteignaient le point où je pouvais obtenir de vraies preuves.
Comment mon workflow Node.js a changé
Je n’ai pas remplacé mon processus de développement par une fenêtre de chat. Dans mes side projects Node.js, j’ai utilisé DeepSeek comme une seconde paire de mains pour des tâches bien délimitées : préparer une première implémentation, lire du code inconnu, proposer des tests, analyser une stack trace, découper un refactoring et revoir des hypothèses de déploiement.
- Scaffolding : produire la première version ennuyeuse de handlers, validation, scripts ou tests.
- Lecture du code : suivre le chemin d’une requête ou d’une valeur avant de modifier quoi que ce soit.
- Refactoring : transformer un gros changement en petits diffs vérifiables.
- Debugging : générer plusieurs hypothèses à partir des logs plutôt que croire la première.
- Vérification : chercher les edge cases et régressions après le happy path.
Plus les inputs, outputs, contraintes et conventions existantes étaient clairs, plus la réponse était facile à vérifier. Une tâche vague produisait plus souvent une abstraction plausible mais incorrecte.
Je traitais donc chaque sortie comme un candidate patch, pas comme une solution finale. Type checking, tests, build et parcours réel étaient des preuves ; une explication assurée ne l’était pas.
Là où DeepSeek m’a le plus aidé — et là où il ne l’a pas fait
DeepSeek m’était surtout utile parce que je pouvais l’utiliser de façon répétée sur des tâches de programmation concrètes. Je pouvais demander un premier passage, rejeter une partie, renvoyer l’erreur réelle, réduire le scope et itérer rapidement.
Je ne présente pas cela comme un benchmark. Je n’ai pas mené d’étude contrôlée contre tous les modèles concurrents et les gammes changent vite. L’affirmation défendable est plus simple : DeepSeek s’intégrait assez bien à mon workflow pour que j’utilise l’assistance AI beaucoup plus souvent.
Il était meilleur quand le feedback coûtait peu : une fonction, des tests et une vraie erreur. Il était moins fiable quand la tâche dépendait de contexte produit implicite ou de choix architecturaux subtils. Dans ces cas, une réponse fluide pouvait rendre une mauvaise hypothèse dangereusement crédible.
L’AI a changé le coût de l’expérimentation
Le principal progrès n’était pas « l’AI écrit du code, donc le développement devient automatique ». Beaucoup de petites pièces sont simplement devenues assez peu coûteuses pour que je puisse tenter de les construire. Une fonctionnalité de side project qui semblait auparavant demander trop de setup pouvait devenir un prototype tant que l’idée m’intéressait encore.
La distinction est importante. L’AI a réduit le coût pour atteindre une version testable. Elle n’a pas supprimé l’architecture, le jugement produit, le déploiement ni la nécessité d’avoir un comportement correct. Une implémentation générée peut être fausse ; un build réussi peut échouer à l’exécution ; un prototype déployé peut rester un mauvais produit.
Pour moi, le bénéfice concret était l’élan. Une fois que je pouvais voir le système entier fonctionner, j’avais beaucoup plus envie de continuer à le raffiner.
Ce qu’exigerait un benchmark plus solide
Pour obtenir un benchmark reproductible, je conserverais les versions exactes des modèles, des tâches de programmation fixes, des snapshots du dépôt, les prompts, les sorties brutes, le temps écoulé, les patches acceptés et rejetés, le temps de review, les résultats des tests et le rework.
Je mesurerais aussi autre chose que les commits : le délai entre l’idée et une version vérifiée, les défauts, les rollbacks et le travail réécrit. Sans ce contexte, 4 000 commits prouvent une activité et un changement de comportement, pas une qualité logicielle.
Ce qui a changé pour moi
2025 a été l’année où j’ai cessé de voir chaque side project comme une montagne de setup à gravir manuellement. L’AI a rendu la première version fonctionnelle assez peu coûteuse pour que j’atteigne plus souvent le moment où les vraies décisions produit deviennent importantes.
C’est la raison pour laquelle la seconde moitié de mon graphique GitHub est si différente. Pas parce que l’AI m’a donné plus d’heures dans une journée, ni parce que chaque ligne générée était bonne. Elle a réduit la friction qui avait tué certaines idées plus anciennes avant qu’elles ne deviennent réelles.
En 2026, je veux surtout travailler sur la partie moins spectaculaire de l’équation : affiner le workflow, mesurer la qualité plus sérieusement et vérifier qu’un développement plus rapide produit de meilleurs logiciels, pas simplement davantage de commits.