Je dirige une boîte de 3D depuis 6 ans. Je code mes SaaS depuis 3 ans. Les deux casquettes, en même temps, sans équipe tech interne. Beaucoup de dirigeants me demandent si c'est tenable. Oui. Mais pas n'importe comment.
Voici ce que j'ai appris à mes dépens.
Le piège
Chaque heure que je passe à coder, c'est une heure que je ne passe pas à :
- Rappeler un client stratégique
- Valider un devis important
- Prendre du recul sur les chiffres
Au début, je ne le voyais pas. Je plongeais dans du code le matin, je levais la tête à 15 h, et je m'apercevais que je n'avais répondu à aucun mail urgent. Pire : j'en prenais du plaisir, parce que coder donne un feedback loop immédiat que la gestion ne donne jamais.
Le danger n'est pas l'inefficacité. C'est la dopamine. Le code est plus gratifiant à court terme que la gestion. Vous finissez par arbitrer inconsciemment en faveur du code. Jusqu'au jour où un vrai problème business explose parce que vous n'étiez pas là.
La force
Mais l'équation a un autre côté. Un dirigeant qui code voit son entreprise autrement :
- Je comprends les données de ma boîte mieux que n'importe quel consultant, parce que je les ai modélisées moi-même.
- Je peux tester une idée business en 48 h — pas en 3 mois. Notre portail apporteurs d'affaires a été lancé en 2 semaines, là où un prestataire nous aurait chiffré 40 k€ et 4 mois.
- Je négocie mieux avec les fournisseurs SaaS parce que je sais ce qu'ils vendent techniquement — et ce qu'ils surfacturent.
- Je recrute mieux, parce que je sais reconnaître un bon tech d'un excellent.
Cette asymétrie est un avantage concurrentiel structurel. Difficile à copier.
Mes 3 règles
J'ai mis du temps à les formuler. Les voici en clair, testées sur 3 ans.
1. Les créneaux de code sont bloqués le matin tôt, ou le soir.
Jamais pendant les heures ouvrées. De 9 h à 18 h, je suis dirigeant. Point. Si je code en journée, c'est après les urgences business — et ça n'arrive que 1 ou 2 fois par semaine.
2. Un projet code ≠ un projet business.
Je distingue clairement mes SaaS persos (InvestBot, ResellOS, etc.) de ma boîte Halte Nuisibles. Quand je code pour Halte Nuisibles (NaviR Field), c'est un projet business — il a un ROI, une deadline, des parties prenantes. Quand je code sur InvestBot, c'est du R&D personnel — pas d'attente de retour.
Cette séparation évite l'auto-justification : « Je code sur mon SaaS perso mais c'est utile à la boîte ». Non. Ce sont deux mondes.
3. Une mission freelance = un contrat cadré.
Quand j'accepte une mission IA ou développement pour un tiers, je la traite comme n'importe quel engagement externe : devis, planning, suivi hebdo. Pas de code « entre deux » en freelance. Sinon je déborde — et c'est ma boîte qui en paie le prix.
Ce que ça coûte
Je ne vais pas vous mentir : cette vie double a un coût.
- Moins de disponibilité pour les loisirs
- Une charge mentale permanente
- Une difficulté à déléguer — parce que je pourrais toujours « faire mieux moi-même »
Le dernier point est le plus dangereux. Un dirigeant-dev qui ne délègue pas devient le goulot d'étranglement de sa boîte. J'ai dû apprendre à accepter du code moyennement bon écrit par quelqu'un d'autre, plutôt que du code excellent que je n'aurais jamais le temps d'écrire.
En conclusion
Être gérant ET développeur, c'est :
- Une arme redoutable pour les dirigeants de PME qui veulent construire vite
- Un piège psychologique si vous ne cadrez pas vos créneaux
- Un atout commercial quand vous commencez à vendre vos compétences en externe
Le bon équilibre se trouve quand le dev sert explicitement la boîte — pas l'inverse.