Quand j'ai repris le DAM en février 2019, le projet n'était pas en retard : il était dans une impasse. 5 chefs de projet s'étaient succédé, plus de 360 000 € avaient été dépensés en licences OpenText, prestataires intégrateurs et pilotage interne, et la plateforme servait à peine 20 personnes là où elle devait équiper les 1 400 salariés du Groupe Pichet. La direction hésitait entre l'abandon pur et un nouveau prestataire - ce qui aurait reproduit le même schéma.

J'ai refusé d'attaquer la solution avant d'avoir reformulé le problème. Avec Stéphanie L., la nouvelle Directrice de la Communication, on a posé 3 questions de fond avant de relancer quoi que ce soit : quel résultat business la plateforme doit produire (faire disparaître la redistribution manuelle d'assets, pas juste héberger des images), quelle réversibilité contractuelle est non-négociable (sortir du SaaS sans lock-in), et à quoi ressemble une journée réussie au jour 90 (un commercial trouve seul son visuel programme en moins de 2 minutes). Une fois ces 3 critères posés, j'ai bâti la méthodologie de benchmark indépendante en 6 étapes et orienté l'évaluation vers Bynder plutôt que vers une nouvelle tentative OpenText.

Bynder est passé en production le 18 novembre 2020, 1 400 utilisateurs onboardés, contrat signé avec clauses de SLA et de réversibilité verrouillées par notre juriste. Là où 5 tentatives avaient échoué, le recadrage a fait livrer le projet en moins de 2 ans pour quelques dizaines de milliers d'euros.

Cette méthode de recadrage - reformuler le problème avant de toucher la solution - est devenue un réflexe que je rejoue aujourd'hui sur chaque mission CTO advisory chez ACCENSEO.

Un projet en échec n'a presque jamais un problème de mauvaise solution, il a un problème de problème mal posé. C'est une thèse classique en management de projet et en design thinking : avant de chercher comment résoudre, il faut s'assurer qu'on a bien identifié quoi résoudre.

Fin 2025, Tailwind v4 est sorti, complètement réécrit en Rust/Oxide. L'unique outil d'obfuscation existant (unplugin-tailwindcss-mangle) reposait sur le patching des internals de Tailwind - approche qui a cassé net avec la v4. Aucune solution compatible n'existait sur le marché, et plusieurs équipes que je conseille avaient explicitement besoin de cet outillage pour livrer leur design system. La fenêtre était courte : 6 semaines avant que la communauté ne se rabatte sur des contournements ad hoc.

J'ai pris une décision contre-intuitive : plutôt que de patcher les internals comme le concurrent, j'ai misé sur l'analyse statique pure - scanner directement les fichiers source pour identifier les classes utilisées, sans dépendre d'aucune internal Tailwind. C'était parier sur une stack que je n'avais jamais touchée : Babel AST pour parser JSX/TSX/Vue/Svelte/Astro/Qwik, PostCSS pour transformer le CSS compilé, magic-string pour les remplacements préservant les sourcemaps, et 5 plugins bundlers (Vite, Webpack, Rollup, esbuild, module Nuxt) partageant le même moteur central. J'ai appris la stack en pair-programming avec Claude Code, en validant chaque hypothèse par des tests.

6 semaines plus tard, j'ai publié tailwindcss-obfuscator sur npm : 82 K lignes de TypeScript, 295 tests, 10 frameworks supportés, détection automatique Tailwind v3 vs v4, monorepo TurboRepo. Premier outil compatible Tailwind v4 sur le marché, adopté par des équipes externes dès les premières semaines.

Ce que je retiens, ce n'est pas l'outil mais la méthode : quand une stack inconnue est sur le chemin critique, on ne contourne pas, on apprend - mais on apprend par le test, pas par le tutoriel. La même mécanique me permettra demain d'absorber Bun + edge runtimes, ou n'importe quelle stack qu'un futur rôle CTO scale-up exigera.

Quand j'ai démarré le SaaS comptable d'ACCENSEO début 2025, je connaissais bien le développement full-stack mais je n'avais aucune expertise comptable formelle. Le domaine ne pardonne pas l'à-peu-près : PCG, CGI, Code de commerce, EDI Teledec, DSP2 pour l'Open Banking, mandat e-facturation 2026-2027. Toute erreur de calcul fiscal a une conséquence financière directe pour le client. Et l'horizon n'était pas modulable : la conformité e-facturation devait être prête avant fin 2026.

J'ai traité la régulation comme une spec système, pas comme une couche métier annexe. J'ai sauvegardé les pages clés du PCG, regardé les outils similaires disponibles sur le marché pour comprendre leurs choix de modélisation et leurs parcours utilisateur, mené une étude de marché des plateformes de dématérialisation (PDP) et un audit de sécurité des SaaS existants (qui a révélé des failles IDOR + KYC chez plusieurs acteurs). Puis j'ai mappé les règles dans des modèles Prisma : 91 modèles, 63 enums, 6 rôles différenciés (Admin, Collaborateur, Consultant, Comptable, Comptabilité, Banque). Pour chaque feature - TVA CA3, IS, CFE, CVAE, DAS2, PAS - j'ai écrit la spec puis des scripts de vérification des calculs avant d'enchaîner les tests de non-régression.

234 K lignes de code livrées en solo, 42 features, 382 routes API, intégration 3 providers Open Banking (GoCardless/Nordigen, Bridge, Qonto), envoi EDI via Teledec, assistant IA multi-fournisseurs (OpenAI, Claude, Gemini), conformité e-facturation 2026-2027 atteinte avant l'échéance.

L'adaptabilité ne m'a pas servi à survivre, elle m'a servi à transformer un domaine régulé en moat produit. C'est exactement la posture que cherche un CTO scale-up B2B en industrie régulée (santé, finance, immobilier institutionnel) : prouver qu'on peut absorber un cadre légal en quelques mois et le coder sans concession.