Dix-sept ans de terrain avant la première ligne de code.
Je ne viens pas du développement. Je viens du terrain, de la gestion d'activité et de l'encadrement d'équipes. C'est là que j'ai vu, tous les jours, l'écart entre ce dont un métier a besoin et ce que les logiciels lui proposent.
J'ai d'abord dirigé, organisé et vendu. Le code est venu après.
Pendant dix-sept ans, j'ai travaillé au contact direct des activités : organisation, encadrement, relation client, gestion quotidienne. J'ai passé mes journées à faire tourner des structures avec les outils du marché, et à constater qu'aucun ne collait vraiment.
On finit toujours par bricoler. Un tableur à côté du logiciel, une feuille de papier pour ce que l'écran ne prévoit pas, une double saisie parce que deux outils ne se parlent pas. Ce bricolage, ce n'est pas un détail : c'est du temps perdu tous les jours, et c'est le vrai symptôme d'un outil mal conçu.
Depuis cinq ans, je consacre l'essentiel de mon temps aux architectures logicielles. Pas pour changer de métier, mais pour pouvoir enfin construire ce qui manquait.
ans de terrain et de direction opérationnelle
ans consacrés aux architectures logicielles
outils métier conçus et développés
Mon premier vrai projet est né d'un besoin que je vivais moi-même.
AquaGymFit a été le déclencheur. Je connaissais l'activité de l'intérieur : les plannings, les adhérents, les intervenants, les rythmes. Je savais précisément ce qui prenait du temps et ce qui n'en prenait pas.
Concevoir cet outil m'a appris la chose la plus importante de mon travail actuel : la difficulté n'est jamais technique. Elle est dans la compréhension du métier. Une fois qu'on a compris comment une activité fonctionne réellement, la solution devient évidente à dessiner.
Je n'ai jamais cherché à faire un logiciel. J'ai cherché à régler un problème que j'avais tous les jours.
Quatre familles de travaux, une seule logique.
Ce sur quoi je ne transige pas.
- 01Comprendre l'activité avant de proposer quoi que ce soit.
- 02Dire non à une fonctionnalité qui ne servira à personne.
- 03Livrer un outil qui appartient à celui qui l'utilise.
- 04Préférer une solution simple qui tient dix ans à une solution brillante qui tient un an.
- 05Rester joignable après la livraison.
- 06Ne jamais enfermer un client dans une dépendance dont il ne peut plus sortir.
Je ne construis pas des projets. Je construis un ensemble cohérent.
Chaque outil que je conçois alimente les suivants. Une brique écrite pour un cahier sert au suivant, l'éditeur qui met à jour un site sert à tous les sites, l'infrastructure qui héberge un projet héberge les autres. C'est ce qui me permet d'aller vite sans sacrifier la qualité, et c'est ce qui fait qu'un client ne reçoit jamais un travail isolé, mais une pièce d'un ensemble qui continue d'évoluer.