Dix ans loin du code, et ce que ça m'a donné pour y revenir

Le 20 août au soir, j’ai rouvert un éditeur de code pour la première fois depuis cinq mois. Pas par envie abstraite : je suis président d’un club de taekwondo, son site WordPress tombait en morceaux, et les inscriptions ouvraient trois semaines plus tard. Une date, des gens qui attendent, pas de budget. Le lendemain, le nouveau site était en ligne.

Il y a dix ans, je n’aurais pas pu faire ça en un jour. Il y a dix ans, pourtant, je codais tous les jours. C’est ce paradoxe que je veux raconter.

S’éloigner du clavier, un poste à la fois

J’ai été développeur pendant sept ans. Java, puis iOS, pour SFR, Natixis, Schneider Electric, un an à Genève en Swift. Je connaissais mes outils, je livrais, j’aimais ça.

Puis, en 2015, Gameloft m’a confié une équipe de vingt-cinq personnes au Vietnam. Plus tard, le product ownership d’une plateforme de paiement pour des banques suisses et françaises. Puis la direction technique d’une société de cent personnes. Puis la création d’un studio de jeu avec 760 k€ d’investissement. Puis l’avant-vente : cadrer, chiffrer, répondre aux appels d’offres, gagner ou perdre.

À chaque poste, moins de code. Et à chaque poste, autre chose à apprendre. Écrire ce qu’on veut avant de le demander. Découper. Savoir où est le risque dans un projet, et où il n’est pas. Dire non à une fonctionnalité. Recruter. Tenir un budget. Relire le travail des autres sans le refaire. Livrer une date qu’on a promise.

Pendant ces dix ans, j’ai gardé une liste. Des projets qui me trottaient dans la tête, jamais commencés. Un buzzer de quiz pour les soirées entre amis. Un jeu de cartes. Un outil pour un vieux jeu de stratégie que je n’ai jamais lâché. Le site du club, refait proprement. Aucun n’a jamais dépassé le stade du carnet. Pas le temps, et surtout un écart qui se creusait chaque année entre ce que je savais faire et ce qu’il fallait savoir pour le faire.

Ce que les outils d’IA ont vraiment changé

On présente souvent le « vibe coding » comme une accélération de la frappe. Ce n’est pas ce que j’ai vécu.

Ce qui me manquait pour exécuter ces projets, ce n’était pas la tête. C’était les mains, et le temps. Ce que j’ai retrouvé en février 2026, quand j’ai essayé Claude Code pour la première fois, c’est une équipe. Une équipe qui écrit vite, qui ne dort pas, qui ne se vexe pas quand on lui dit de recommencer, et qui a exactement les défauts d’une équipe : elle fait ce qu’on lui demande, pas ce qu’on voulait. Elle ne vérifie pas sur un vrai téléphone. Elle produit un plan en dix-neuf sprints pour un jeu qui sera publié six jours plus tard.

Autrement dit : ce qu’il faut savoir faire pour bien travailler avec ces outils, c’est exactement ce que j’ai passé dix ans à apprendre en m’éloignant du code.

Deux exemples concrets.

WhatToPlay, quinze jours, trente-neuf pull requests

L’idée est simple : le catalogue PlayStation Plus est énorme, et je voulais juste savoir quoi jouer, trié par note. Le 30 août, j’ai commencé. Le 13 septembre, le site tournait en six langues sur dix pays, mis à jour chaque nuit.

La récupération des données. Le premier réflexe aurait été de scraper le site de Sony. J’ai demandé d’abord de regarder comment la liste A-Z publique de playstation.com se remplissait. Réponse : un point d’accès JSON, non documenté mais stable, qui renvoie tout le catalogue d’un pays avec les identifiants, les jaquettes et les dates. Une heure de cadrage, et la panne la plus probable du projet n’existait plus. C’est une décision d’avant-vente, pas de développeur : trouver où est le risque avant d’écrire une ligne.

Les notes. Ni Sony ni personne ne publie un catalogue avec les notes presse. Il a fallu recouper : RAWG pour Metacritic, Steam en secours quand l’inscription RAWG a cessé de fonctionner, HowLongToBeat pour les durées, IGDB en troisième source pour passer de 64 à 72 % de couverture. Un titre n’est pas un identifiant : « Nom du jeu », « Nom du jeu™ », « Nom du jeu — Director’s Cut » sont le même jeu ou pas selon la source. L’outil a écrit la collecte sans que j’aie grand-chose à corriger. Il n’a rien pu faire pour le recoupement, parce que ce n’est pas un problème de code : c’est trois cents petites décisions. Ça, c’est le product owner qui les prend.

Le design. Une première interface le 30 août, moche mais qui marche. Une refonte éditoriale le 31, avec tri par en-têtes et thème sombre. Une refonte du système visuel le 11 septembre, après dix jours à m’en servir tous les soirs. Je n’ai jamais demandé « fais-moi un beau site ». J’ai demandé une chose à la fois, regardé le résultat, corrigé. Prompt après prompt, comme on fait des revues de sprint.

Le déploiement. L’ingestion tourne dans GitHub Actions, à 05 h 17 UTC, et commite les données dans le dépôt, ce qui redéploie le site sur Vercel. Ce n’est pas le choix par défaut ; le choix par défaut, c’est un cron chez l’hébergeur. Mais le plan gratuit plafonne la durée des fonctions, et dix pays fois plusieurs centaines de jeux ne rentrent pas. Avec Actions, l’historique du catalogue est gratuit et un retour arrière tient en un git revert. C’est une décision de directeur technique : une architecture qu’une seule personne peut tenir.

La méthode. Trente-neuf pull requests en quinze jours, une par sujet. Un coupe-circuit par fournisseur de données quand le cron s’est mis à échouer. Un audit SEO reproductible en une commande. Ce sont des réflexes de manager, pas de codeur : on ne mélange pas deux sujets dans une livraison, et ce qui a cassé une fois doit être détecté la fois d’après.

Taekwondo Meylan, ou comment WordPress est devenu des fichiers texte

Le site du club, c’est l’autre exemple, et le plus parlant sur ce que les années de management apportent.

Le WordPress avait un thème premium, un constructeur de pages, et un seul administrateur : moi. Les horaires étaient dupliqués entre la page d’accueil et les fiches de cours. Le lien d’inscription HelloAsso change chaque saison, et en août 2026, la page d’accueil pointait encore sur le formulaire de 2025-2026. Personne ne l’avait vu.

Le nouveau site est en Astro. Le contenu est du texte versionné : un fichier YAML pour les horaires, les tarifs et les liens, un fichier Markdown par membre de l’équipe, par article, par évènement. Et un schéma qui refuse de construire le site si le contenu est incohérent : un cours sans horaire, un grade écrit « 3eme Dan » au lieu de « 3e dan », un lien HelloAsso qui ne porte pas la saison en cours. Ce contrôle-là aurait évité l’erreur d’août.

Le résultat : 104 redirections depuis les anciennes adresses, vérifiées à chaque déploiement. Une police servie depuis le site au lieu de Google Fonts, et Lighthouse mobile qui passe de 94 à 99, le premier affichage de 2,5 à 0,9 seconde. Une image de partage de 3,3 Mo qui devient 141 ko. Et pour les bénévoles, un chat d’administration où l’on écrit « décale le cours du mercredi à 18 h 15 », qui prépare un brouillon sur une branche, montre un aperçu, et ne publie que si quelqu’un clique sur Publier. Ce bouton n’est pas un outil de l’agent. C’est le seul chemin vers la production.

Je reviens plus longuement sur ce site dans l’entrée suivante : il a vingt-cinq ans, et c’est sa cinquième version.

Ce que dix ans de management ont donné à mes soirées

Quand je regarde comment je travaille sur ces projets, je vois chaque poste que j’ai occupé.

Le product owner écrit ce qu’il veut avant de demander. Un document de conception de trois pages a produit un jeu de cartes publié en six jours. Un brief flou a produit deux projets morts en février, avec des centaines de pages de documentation et zéro ligne utile.

L’estimateur sait où est le risque. Le premier jour, l’outil produit un plan en dix-neuf sprints. Je lis l’ordre, j’ignore les durées : la séquence reste juste, le calendrier n’a plus de sens. Et je sais que le bug qui ne se produit que sur un Galaxy A33 coûtera trois jours, quel que soit l’outil.

Le directeur technique choisit une architecture qu’une personne peut tenir. Pas de framework quand deux lignes suffisent. Pas de base de données quand des fichiers versionnés font le travail. Le cron là où il rentre dans le budget.

Le producteur coupe. La question que je me pose avant tout projet : qu’est-ce que je peux mettre entre les mains de quelqu’un ce soir ? Si la réponse est « rien, il faut d’abord cadrer », je cadre sur une page, pas cinquante-cinq.

Et le manager relit. Un script qu’on n’a pas écrit, on ne sait pas ce qu’il ne fait pas. On l’essaie sur cinq cas avant de le lancer sur tout. On ouvre le site sur un vrai téléphone. On ne fait pas confiance, on vérifie, et on le fait sans vexer personne, ce qui, avec un outil, est enfin facile.

Ces projets étaient dans ma tête depuis des années.

Ce n’est pas l’IA qui les a construits. C’est une équipe que je dirige le soir, avec ce que j’ai appris le jour.