Le vibe coding efficace bouscule des certitudes de développeurs et recruteurs vieilles de plusieurs décennies
Ces dernières années, nous utilisions clockify.me pour générer les rapports de temps sur lesquels sont basées certaines de nos factures de prestation de service. Clockify a drastiquement changé son offre, et nous en sommes venus à n'utiliser que ses exports CSV comme source pour générer ces factures.
Nous avons cherché des alternatives OpenSource mais aucune ne nous a vraiment convaincus : certaines se résumaient à de simples pomodoros, d'autres reposaient sur des stacks avec un footprint bien trop lourd à notre goût. Parmi les plus connues, Kimai ou Solidtime par exemple sont écrits en PHP, ce qui implique de faire tourner de l'Apache ou du php-fpm.
Entre cette déception et le fait que nous ne voulions pas réécrire d'un coup tout notre pipeline de facturation, basé sur des cronjobs CI/CD GitLab, nous avons pris la décision de construire une application ayant exactement le même contrat d'interface pour les exports que Clockify, tout en permettant de réingérer les exports en provenance de Clockify pour ne pas perdre toutes nos années d'historique.
Nous sommes ensuite allés plus loin en développant, toujours en OpenSource, tout ce qui manquait à Clockify :
- Des RBAC mieux découpés, avec des personnes ayant accès aux données financières (TJM, etc.) et d'autres uniquement aux temps
- Des export jobs qui permettent d'automatiser l'envoi de factures ou de feuilles de temps avec des expressions dynamiques (cron pour le scheduling, syntaxe
now()-1dpour les intervalles de temps) - Une CLI agentique avec serveur MCP intégré, que l'on peut invoquer depuis nos fonctions serverless low-code via l'API CWAI
- Une application mobile ergonomique
- Une vue calendrier compatible avec Google Calendar ou Microsoft Outlook
- Une gestion des feuilles de temps à la journée ou à la demi-journée pour les prestations qui ne sont pas facturées à l'heure
- Une matrice de décision pour la configuration des données obligatoires selon les différents pays
- Etc
Et c'est ainsi qu'est né cwclock.me1, construit avec les technologies suivantes :
- Go pour l'API (api.cwclock.me), la CLI et le serveur MCP
- Flutter pour l'application mobile
- React pour la version web
- PostgreSQL pour la base de données
Le tout construit sur la base d'une centaine de prompts, qui font eux-mêmes intégralement partie du code source, dont les repos sont disponibles ici :
Cette expérience nous a amenés à remettre en question certains principes dont nous étions convaincus depuis plusieurs années, et c'est ce que je voulais partager ici.
Choisir un langage de programmation simple et consensuel sur le marché comme PHP, Python, TypeScript ou JavaScript, pour pouvoir recruter plus facilement
Ce n'est clairement plus là que se joue le nerf de la guerre aujourd'hui. Entre Kubernetes, Docker et la quasi-totalité des outils CNCF écrits en Go, ou encore toutes les plateformes désormais écrites en Rust, des modèles comme Claude Opus & co. sont extrêmement bien entraînés pour écrire du code propre et lisible en Go et en Rust.
La difficulté de recrutement sur ces langages n'est plus vraiment un sujet, et il vaut mieux désormais privilégier des technologies au footprint léger, portées par suffisamment de gros projets OpenSource pour garantir leur viabilité dans le temps, et disposant de suffisamment de code source disponible pour entraîner les LLM optimisés pour la génération de code.
Mono-repo vs multi-repo
Il y avait de nombreux arguments, plutôt portés par des développeurs hyper spécialisés, pour affirmer qu'il valait mieux des repos séparés avec une stricte separation of concerns : un développeur front n'a besoin que de la spec OpenAPI, pas de télécharger toute la codebase backend qu'il ne comprend pas, et inversement.
Avec le vibe coding, c'est exactement l'inverse : plus un modèle dispose de contexte en entrée, moins il consomme de tokens en raisonnement pour accomplir la tâche demandée, et moins il y a d'allers-retours nécessaires avec lui. Et il n'y a clairement pas de meilleure spécification que le code lui-même. Donc quand on demande un changement qui impacte l'API et tous ses clients (frontend, mobile, CLI, provider Terraform, Helm chart, etc.), il vaut mieux que tout soit dans le même repo. Après des années à militer pour le multi-repo, je reviens donc complètement sur cette opinion, à titre personnel.
Ne pas multiplier les technologies dans sa codebase
Pendant des décennies, la majorité des entreprises se sont interdit d'écouter le bon sens qui dit que « chaque techno a des domaines où elle est plus ou moins efficace », en se disant plutôt qu'il valait mieux un seul langage de programmation. Cela a donné le « tout Python » ou le « tout TypeScript », alors même que l'on sait pertinemment que ces technologies ne sont pas efficaces pour un grand nombre de cas d'usage.
Dans le lot, on retrouve React Native, censé permettre de réutiliser la même codebase entre le front web et l'application mobile. Quand on s'y intéresse de près, on voit clairement que cela demande une lourde maintenance.
Là encore, ce n'est plus vraiment un argument valable. Si vous tentez l'expérience, vous verrez que Claude a beaucoup plus de mal à générer, du premier coup, du code React Native qui fonctionne : une fois sur deux environ, on tombe sur des incompatibilités de packages Node avec Kotlin, là où avec Flutter, il est très efficace et ne se plante quasiment jamais. On pourrait penser que c'est dommage d'avoir deux codebases, React pour le web et Flutter pour le mobile, mais en réalité c'est tout l'inverse : pour les agents, cela ne fait que renforcer le poids du contexte disponible pour savoir exactement comment implémenter la même fonctionnalité dans une autre techno, comme la CLI en Go, ou pourquoi pas une autre application mobile davantage optimisée pour iOS, en Swift par exemple.
Le ROI d'une réécriture en mode big bang est rarement positif
Quand une codebase posait des problèmes de maintenabilité, il fallait auparavant calculer le retour sur investissement d'une réécriture complète par rapport au temps englouti à la maintenir en l'état. Et bien souvent, la conclusion était qu'il valait mieux prolonger sa durée de vie tant bien que mal.
Désormais, une vieille codebase legacy est le meilleur contexte possible pour demander à des modèles une réécriture complète, en corrigeant au passage les défauts identifiés depuis des années. C'est le moment idéal pour enfin vous attaquer à tous ces projets de refactoring que vous jugiez trop coûteux jusque-là.
Conclusion
A la dernière conférence DevoxxFR 2026 je discutais avec un des developer advocate de copilot qui disait qu'il ne restera que TypeScript comme langage de programmation avec des arguments qui font sens d'un point de vue "old-school HR management". Mais je pense sincèrement qu'il fait fausse route avec toutes les raisons que j'ai énoncé ici.
Avec le vibe coding, il vaut mieux choisir des technos sur lesquelles les modèles sont bien entraînés, non pas parce qu'elles sont massivement adoptées, mais parce qu'il existe des projets OpenSource de qualité qui leur ont servi de base d'entraînement et qui sont plus optimisés et plus proches de leur plateforme d'exécution. La maintenabilité et le run coûteront également bien moins cher aux entreprises.
La valeur des langages de scripts "haut niveau" et "simples" s'effondre complètement lorsque l'on deviens capable d'intéragir avec la machine directement en langage humain.
En outre, nous ne sommes pas les seuls à avoir eu cette idée :
Aujourd'hui, le développement d'applications sur mesure est en train de devenir une commodité accessible à toutes et tous. Nous ne savons pas combien de temps cela va durer, ni quelles conditions y mettront fin et en restreindront de nouveau l'accès (augmentation drastique des coûts des providers comme Anthropic ou OpenAI pour devenir rentables, géopolitique, fin du capitalisme, peu importe). Mais notre position est qu'il faut en profiter dès maintenant pour enrichir l'OpenSource, afin de continuer à en bénéficier même si cela venait à s'arrêter un jour.