Un fondateur que j'accompagne m'a posé la question un lundi matin : « La tech, ça va ? » J'ai tiré les chiffres. 47 incidents en production sur les 6 derniers mois. Des pages blanches, des données qui ne s'enregistrent pas, un paiement en double. Il pensait qu'il y en avait eu 3 ou 4.
Ce fondateur n'est pas négligent. Il suit son chiffre d'affaires au centime, son taux de conversion à la décimale. Mais côté technique, il naviguait à l'aveugle — et sa dette technique grossissait sans qu'il le sache. Ce n'est pas un cas isolé. C'est la norme.
Voici les 6 indicateurs que je fais suivre à chaque dirigeant que j'accompagne. Pas de jargon, pas besoin de coder. Juste 6 chiffres à demander chaque mois.
Pourquoi la tech est le seul département sans tableau de bord
Votre directeur commercial a un pipe, un taux de conversion, un panier moyen. Votre DAF suit la trésorerie, le BFR, les marges. Et la tech ? La tech, c'est « ça avance » ou « c'est compliqué ».
Le problème n'est pas technique. C'est un problème de traduction. Les développeurs parlent en sprints, en story points, en refactoring. Les dirigeants entendent du bruit. Personne ne fait le pont entre les deux mondes.
J'ai vu des fondateurs prendre des décisions à 100 000 € — recrutement, refonte, changement de prestataire — sur la base d'une sensation. « J'ai l'impression que c'est lent. » « Mon dev me dit que c'est la galère. » C'est comme piloter votre trésorerie au feeling. Ça marche un temps. Puis ça casse.
KPI #1 — La vélocité de livraison
Un fondateur m'a montré son dashboard Jira. 127 points de vélocité sur le sprint. « Regarde, ça progresse ! » J'ai regardé ce qui était réellement en production. Une seule modification visible en trois semaines : un changement de couleur sur un bouton.
Les 127 points ? De la plomberie interne, du remboursement de dette technique, du refactoring. Utile, mais pas de la valeur livrée aux utilisateurs.
La vélocité qui compte pour un dirigeant, ce n'est pas un score dans Jira. C'est le nombre de fonctionnalités nouvelles qui arrivent entre les mains de vos clients chaque mois. Demandez : « Combien de features visibles sont en production ce mois-ci ? » Si le chiffre baisse trois mois de suite avec la même équipe, quelque chose bloque. Peut-être la dette technique, peut-être autre chose — mais vous devez le savoir.
KPI #2 — La fréquence de déploiement
Une startup que j'ai auditée mettait trois semaines entre chaque mise en production. Chaque déploiement nécessitait un week-end complet. Le CTO faisait tout à la main : backup, migration de base, redémarrage, tests manuels. Le jour où il est parti en vacances, l'app est tombée. Personne ne savait la remettre en route. Trois jours d'interruption.
La fréquence de déploiement mesure combien de fois par mois votre équipe met à jour l'application en production. C'est le meilleur indicateur de maturité technique que je connaisse. C'est aussi l'un des premiers que les investisseurs vérifient en due diligence.
Les seuils :
- Plusieurs fois par semaine → équipe mature, process rodés
- Une à deux fois par mois → correct pour une petite équipe
- Moins d'une fois par mois → fragile. Chaque déploiement devient un événement stressant, donc l'équipe en fait le moins possible, donc les changements s'accumulent, donc le prochain sera encore plus risqué. Cercle vicieux classique.
KPI #3 — Le nombre d'incidents en production
Revenons aux 47 incidents du début. Le fondateur ne les comptait pas. Ses utilisateurs, si. Son support client avait une feuille Excel avec les signalements, mais personne ne la consolidait ni ne la transmettait à la tech. En croisant les données : 47 incidents dont 8 avec perte temporaire de données. Un utilisateur avait perdu l'historique de ses commandes pendant 4 jours. Côté tech, personne n'était au courant.
Suivez deux choses : le nombre et la tendance. 12 incidents en janvier et 5 en mars, c'est une équipe qui corrige. 5 en janvier et 12 en mars, c'est une application qui se dégrade. Et faites la distinction entre un bouton cassé sur Safari et une faille qui expose les données de vos clients. Un incident critique par trimestre, c'est déjà trop.
KPI #4 — Le ratio de dette technique
Posez cette question à votre équipe technique : « Sur les 4 dernières semaines, quel pourcentage du temps a été consacré à corriger des bugs, refaire du code existant ou gérer des problèmes techniques — par opposition à développer des nouvelles fonctionnalités ? »
La réponse, c'est votre ratio de dette technique. En dessous de 20%, l'équipe consacre l'essentiel de son temps à avancer. Entre 20% et 40%, la dette commence à peser — chaque nouvelle feature prend plus de temps qu'elle ne devrait. Au-dessus de 40%, vous avez un problème sérieux.
J'ai audité une startup où le ratio était à 65%. Deux tiers du temps de l'équipe servait à empêcher l'existant de s'effondrer. Le fondateur se demandait pourquoi chaque fonctionnalité prenait trois mois. Maintenant il savait. Le coût réel de cette dette se chiffrait en centaines de milliers d'euros de retard sur la roadmap.
Votre app a ces failles ?
Architecture, recrutement, process — un CTO senior sans embaucher à plein temps.
Discuter de mon projetKPI #5 — La couverture de tests
Imaginez que votre équipe modifie une partie du code. Comment savoir si cette modification n'a pas cassé autre chose ? C'est le rôle des tests automatisés : un filet de sécurité qui vérifie que tout fonctionne encore après chaque changement. La couverture de tests, c'est le pourcentage du code protégé par ce filet.
Un fonds d'investissement m'a envoyé un repo à auditer. La startup levait 1,2 million d'euros. Produit en ligne, utilisateurs actifs, métriques business solides. J'ouvre le code : 0% de couverture. Pas un seul test automatisé dans tout le projet. Le fonds a fermé le dossier dans la semaine. Ce n'est pas le zéro qui a tué le deal — c'est ce que ça révélait sur la rigueur de l'équipe.
La couverture de tests est le premier indicateur que les investisseurs vérifient en due diligence. Au-dessus de 70%, vous êtes solide. Entre 40% et 70%, c'est acceptable si la tendance monte. En dessous de 40%, chaque modification est un pari.
KPI #6 — Le temps de correction
Un de mes clients a subi un incident de sécurité. Une faille permettait d'accéder aux données d'autres utilisateurs. Temps de correction : 72 heures. Trois jours pendant lesquels la faille était exploitable. Pas par incompétence — le code était si enchevêtré que trouver l'origine du problème a pris 2 jours à lui seul.
Le MTTR — Mean Time To Repair, ou temps moyen de correction — révèle la capacité de réaction de votre équipe quand les choses tournent mal. Moins de 4 heures pour un incident critique, c'est une équipe mature avec des process en place. Entre 4 et 24 heures, c'est correct. Au-delà de 24 heures, votre équipe est soit débordée, soit freinée par un code trop complexe. Dans les deux cas, c'est le signe d'erreurs structurelles à traiter avant qu'un vrai incident ne vous coûte des clients.
Le dashboard « 6 KPI tech pour le board »
Voici le tableau que je fais installer chez chaque client. Une ligne par KPI, mise à jour mensuelle, 5 minutes de lecture en comité de direction.
| # | KPI | Ce qu'il mesure | 🟢 Sain | 🟠 Attention | 🔴 Alerte |
|---|---|---|---|---|---|
| 1 | Vélocité de livraison | Features en production / mois | Stable ou en hausse | Baisse depuis 2 mois | Baisse depuis 3+ mois |
| 2 | Fréquence de déploiement | Mises en production / mois | 4+ / mois | 1-2 / mois | < 1 / mois |
| 3 | Incidents production | Bugs critiques / mois | 0-1 | 2-4 | 5+ |
| 4 | Ratio dette technique | % temps sur le legacy | < 20% | 20-40% | > 40% |
| 5 | Couverture de tests | % code testé automatiquement | > 70% | 40-70% | < 40% |
| 6 | Temps de correction | Heures pour résoudre un critique | < 4h | 4-24h | > 24h |
Imprimez-le. Affichez-le. Demandez une mise à jour chaque premier lundi du mois.
Comment obtenir ces chiffres sans micro-manager
Le piège serait de transformer ces KPI en outil de surveillance. Ce n'est pas le but. L'objectif est d'avoir une conversation factuelle sur la santé technique.
Demandez, n'espionnez pas. Envoyez ce tableau à votre lead dev ou CTO et dites : « Je voudrais suivre ces 6 indicateurs chaque mois. Comment on fait ? » Si l'équipe est compétente, elle trouvera ça normal. La plupart de ces données existent déjà dans leurs outils.
Si l'équipe résiste, c'est un signal. Un bon développeur n'a aucun problème à partager des métriques de qualité. Si la réponse est « on ne peut pas mesurer ça » ou « ça ne sert à rien », creusez. Soit les outils manquent, soit les chiffres ne sont pas bons et personne ne veut les montrer. Dans les deux cas, c'est un problème à régler — et c'est aussi un critère à évaluer quand vous recrutez un profil technique.
Vous n'avez pas de CTO ? C'est exactement ce que fait un CTO externalisé : structurer le pilotage technique, installer les bons outils de mesure, et traduire les données en décisions business. Pas besoin d'embaucher à plein temps pour ça.
Vous n'avez aucune de ces métriques aujourd'hui ? Commencez par une seule : le nombre d'incidents en production ce mois-ci. C'est la plus facile à obtenir et la plus révélatrice. Si le chiffre vous surprend, les cinq autres vous surprendront aussi.