Dette technique : 5 leviers quand on est fondateur non-tech

L'an dernier, un fondateur m'a appelé en panique. Son dev freelance venait de partir — et avec lui, tous les accès à l'application. Hébergement, code, nom de domaine. Tout. 18 mois de développement, 120 000 € investis, et ce dirigeant ne pouvait même pas se connecter à son propre serveur.

Ce cas est extrême. Le problème qu'il illustre ne l'est pas. Quand vous êtes fondateur non-technique, le cœur de votre produit repose sur quelque chose que vous ne maîtrisez pas. Cette dépendance crée un angle mort où la dette technique informatique s'accumule en silence — des raccourcis invisibles qui ralentissent votre produit, plombent votre budget, et vous échappent complètement.

Vous n'avez pas besoin d'apprendre à coder pour reprendre la main. Il vous faut 5 mécanismes. Je les installe chez chacun de mes clients, et ils changent la donne en quelques semaines.

Vous contrôlez votre compta sans être comptable — faites pareil avec la tech

Personne ne dit "je ne comprends rien à la finance, donc je laisse mon comptable décider du budget". Vous avez un expert-comptable, mais vous regardez vos tableaux de bord. Vous posez des questions. Vous validez les orientations.

Avec la tech, c'est exactement la même logique.

Le problème que je vois chez la majorité des fondateurs que j'accompagne, ce n'est pas un manque de compétence technique. C'est une asymétrie d'information. Votre dev sait tout, vous ne savez rien. Et cette asymétrie crée un déséquilibre de pouvoir qui n'a rien à voir avec la hiérarchie : celui qui détient l'information prend les décisions.

La dette technique a un coût réel — mais le premier coût, c'est celui de ne pas savoir qu'elle s'accumule.

Levier 1 — Le point hebdo structuré

Je ne parle pas d'un standup où votre dev récite ce qu'il a fait. Je parle d'un échange de 30 minutes où vous posez les bonnes questions.

Un fondateur que j'ai accompagné pendant 6 mois a transformé sa relation avec son équipe tech en posant 5 questions à chaque point hebdo :

1. Qu'est-ce qui a été livré cette semaine aux utilisateurs ? Pas "travaillé sur", pas "avancé". Livré. Disponible. Utilisable.
2. Qu'est-ce qui bloque ? Un dev qui dit "rien ne bloque" chaque semaine, c'est suspect. Il y a toujours des frictions.
3. Est-ce qu'on a pris des raccourcis cette semaine, et lesquels ? C'est la question la plus puissante. Elle normalise les raccourcis (c'est inévitable) tout en les rendant visibles.
4. Qu'est-ce qui me surprendrait si je regardais le code aujourd'hui ? Question ouverte, volontairement large. Elle ouvre la porte aux aveux.
5. Est-ce qu'on est toujours alignés sur les priorités du mois ?

En 2 mois, ce fondateur est passé de "je ne sais pas ce qui se passe" à "j'ai une vision claire de l'état de mon produit". Sans jamais avoir ouvert un éditeur de code.

Point crucial : ce n'est pas un interrogatoire. Si votre dev le perçoit comme du flicage, ça ne marchera pas. Partagez aussi vos priorités business, vos retours clients, vos chiffres. L'information doit circuler dans les deux sens.

Levier 2 — Trois KPI pour détecter la dette technique informatique

Vous n'avez pas besoin d'un tableau de bord à 15 métriques. Trois chiffres suffisent.

La fréquence de déploiement. Combien de fois par semaine votre équipe met-elle du nouveau code en production ? Un déploiement par semaine minimum, c'est sain. Un par mois, il y a un problème — soit de process, soit de dette technique qui rend chaque changement risqué.

J'ai vu un fondateur commencer à noter ce seul chiffre. Son dev déployait une fois par mois. En creusant, il a découvert que chaque déploiement prenait une demi-journée de manipulations manuelles parce que rien n'était automatisé. Une journée d'investissement pour automatiser, et ils sont passés à 3 déploiements par semaine. Le fondateur n'a rien compris techniquement. Mais il a vu le changement dans les chiffres — et dans la vitesse à laquelle les retours clients étaient pris en compte.

Le nombre de bugs remontés par les utilisateurs. Pas les bugs internes. Ceux que vos clients voient. Si ce chiffre monte, c'est un signal. Si personne ne le mesure, c'est un signal encore plus fort.

Le ratio features vs maintenance. Sur les 10 derniers jours de travail, combien ont été consacrés à de nouvelles fonctionnalités, et combien à corriger l'existant ? Un ratio sain tourne autour de 70/30. Si votre dev passe la majorité de son temps à colmater, vous avez un problème de dette. Votre application est peut-être lente pour une raison plus simple qu'il n'y paraît — mais seul un diagnostic honnête le dira.

Levier 3 — L'audit externe ponctuel

C'est l'équivalent du commissaire aux comptes pour votre code. Un regard extérieur, indépendant, qui vous dit où vous en êtes.

J'ai audité le code d'une startup après 12 mois de développement. Le fondateur était satisfait — les features arrivaient, les clients étaient contents. L'audit a révélé : zéro test automatisé, des mots de passe en clair dans le code source, aucun système de sauvegarde. Le dev n'était pas incompétent. Il était seul, pressé, et personne ne vérifiait son travail.

Ce fondateur n'a pas viré son dev. Il a utilisé le rapport d'audit pour prioriser ensemble les sujets critiques. En 6 semaines, les problèmes de sécurité étaient réglés. La relation de travail est devenue plus saine, parce que les deux parties avaient enfin une base factuelle pour discuter.

Un audit coûte entre 1 500 et 5 000 € selon la taille de l'application — le détail des prix et livrables est ici. Ce n'est pas un luxe, c'est une assurance. À faire une fois par an, ou à chaque jalon important : avant une levée, avant un gros recrutement tech, quand vous changez de prestataire.

Levier 4 — La roadmap partagée

Un dirigeant m'a contacté parce que son dev lui répondait "on refactorise" depuis 3 mois à chaque question sur les prochaines fonctionnalités. En creusant, j'ai découvert que le dev réécrivait une partie du code en utilisant un framework qu'il voulait apprendre — en partie pour son portfolio personnel. Pas de malveillance, juste un désalignement total entre ses priorités et celles de l'entreprise.

La solution tient en un document simple, visible par tous :

• Les objectifs business du trimestre — en haut, en gras, non négociables
• Les fonctionnalités prévues pour y répondre, classées par priorité
• Le budget dette technique — oui, c'est un budget, comme le budget marketing. J'alloue 20 à 30 % du temps de développement à la maintenance. Pas plus sans justification chiffrée, pas moins sans risque d'explosion

L'exercice force la conversation. Votre dev doit expliquer pourquoi telle refonte est nécessaire — en termes d'impact business. "Si on ne fait pas ça, on ne pourra pas supporter plus de 500 utilisateurs simultanés" est un argument recevable. "C'est plus propre comme ça" ne l'est pas.

Savoir si une refonte vaut le coup est une question à laquelle vous avez le droit d'obtenir une réponse claire. Exigez-la.

Levier 5 — Les accès et la propriété

Revenons à l'anecdote d'ouverture. Ce fondateur avait tout perdu parce que chaque compte était au nom personnel de son dev.

Ce que vous devez posséder, au nom de votre société, sans exception :

• Repository de code (GitHub, GitLab) — compte admin société
• Hébergement (AWS, OVH, Scaleway) — facturé à la société
• Nom de domaine — enregistré au nom de la société
• Comptes stores (App Store, Google Play) si vous avez une app mobile
• Service d'emails transactionnels (Sendgrid, Mailgun)
• Sauvegardes — et vérifier qu'elles fonctionnent, pas juste qu'elles existent
• Outils de suivi (analytics, monitoring)

Si un seul de ces éléments est au nom personnel de votre dev ou de votre agence, corrigez-le cette semaine. Pas le mois prochain. Cette semaine.

Ce n'est pas une question de confiance. C'est de la gestion des risques. Votre dev peut tomber malade, changer de pays, ou démissionner. Ce jour-là, vous devez pouvoir continuer sans lui. La checklist complète de sécurité pour dirigeants couvre les autres points à vérifier.

Le signal que vous ne pouvez pas ignorer

Si vous mettez en place ces 5 leviers et que vous rencontrez de la résistance, écoutez ce signal.

Un bon développeur n'a aucun problème avec la transparence. Montrer ses déploiements, partager une roadmap, donner les accès — c'est normal. C'est un signe de professionnalisme.

La résistance légitime existe : un dev débordé peut repousser un point hebdo par manque de temps. C'est une question d'organisation. Mais un dev qui refuse de vous donner accès au serveur ou qui ne veut pas qu'un œil extérieur regarde son code ? C'est autre chose. Et ça dépasse le sujet de la dette technique.

Par où commencer

Vous n'avez pas besoin de tout installer d'un coup. Cette semaine, faites une chose.

Vérifiez vos accès. Ouvrez votre navigateur et connectez-vous au repo de code, à l'hébergeur, au registrar du domaine. Si vous n'avez pas les identifiants, demandez-les aujourd'hui. Si on vous les refuse, vous savez où vous en êtes.

Une fois les accès sécurisés, instaurez le point hebdo. Puis commencez à noter la fréquence de déploiement. Le reste viendra. Quand vous posez les bonnes questions, vous comprenez vite où sont les zones d'ombre.

Si vous sentez que vous avez besoin d'un regard extérieur pour structurer tout ça — quelqu'un qui parle tech et business — c'est exactement ce que je fais en tant que CTO externe.