Vous n'avez pas de CTO. Vous avez un lead dev, peut-être un prestataire, peut-être une petite équipe interne. Et vous avez le sentiment de ne pas vraiment contrôler ce qui se passe côté technique. Ce sentiment est valide, mais il ne nécessite pas forcément de recruter ou d'externaliser immédiatement. Il existe cinq actions concrètes, faisables cette semaine, qui vous donneront une visibilité réelle sur votre tech sans expertise technique.
La vélocité est la quantité de travail réellement livrée et déployée par sprint. Si vous utilisez Jira, Linear, ou même Trello, vous pouvez la calculer en 30 minutes. Prenez les 8 derniers sprints. Pour chacun : combien de tickets étaient planifiés au début, combien ont été livrés et déployés à la fin ? Le ratio vous donne votre taux de complétion réel.
Un taux régulièrement inférieur à 65-70% n'est pas normal. Ce n'est pas que votre équipe est paresseuse : c'est que les estimations sont mauvaises, que la dette technique ralentit chaque livraison, ou que les priorités changent trop souvent en cours de sprint. Ce chiffre seul vous donnera une base de conversation factuelle avec votre équipe.
- Ouvrez votre outil de gestion de tickets (Jira, Linear, Notion, Trello).
- Listez les 8 derniers sprints avec : tickets planifiés / tickets livrés / tickets déployés.
- Calculez le ratio livré/planifié pour chaque sprint.
- Présentez le résultat en réunion d'équipe et demandez ce qui explique les écarts.
Vous n'avez pas besoin de comprendre le code pour créer un registre de dette technique. Vous avez besoin de demander à votre lead dev de le remplir. Organisez une réunion d'une heure avec lui, un tableur ouvert, et ces quatre colonnes : description du problème en langage non-technique, impact sur les livraisons (1 à 5), effort estimé pour le corriger (1 à 5), risque si on ne le corrige pas (1 à 5).
Le résultat : une liste priorisée que vous comprenez, que votre lead dev valide, et qui vous permet de prendre des décisions d'allocation de ressources informées. Ce registre sera votre premier outil de pilotage technique en tant que non-développeur.
- Bloquez 1 heure avec votre lead dev, expliquez l'objectif : voir ensemble ce qui freine.
- Créez un Google Sheet avec les colonnes : Problème / Impact livraisons / Effort correction / Risque si non traité.
- Remplissez ensemble les 10 premiers items. Pas besoin d'exhaustivité : commencez par ce qui revient le plus souvent dans les conversations.
- Classez par score impact × risque. Les items en haut de liste sont vos priorités.
Combien d'anciens prestataires ont encore accès à votre infrastructure ? Combien de personnes connaissent le mot de passe root de votre serveur de production ? Si vous ne savez pas répondre à ces questions immédiatement, vous avez un problème de sécurité actif — pas théorique.
Cet audit ne nécessite pas de compétence technique. Il nécessite de poser les bonnes questions et de documenter les réponses. La plupart des PME découvrent à cette occasion que 3 à 5 personnes qui ne travaillent plus avec elles ont encore des accès actifs.
- Demandez à votre lead dev la liste complète des services et outils utilisés (hébergement, base de données, GitHub, Slack, outils SaaS).
- Pour chaque service : qui a accès, quel niveau d'accès, depuis quand ?
- Vérifiez que les prestataires terminés et les anciens employés n'ont plus d'accès actifs.
- Activez l'authentification à deux facteurs (2FA) sur tous les services critiques si ce n'est pas déjà fait.
"C'est fait" veut dire quoi exactement dans votre équipe ? Développé en local ? Testé ? Mergé ? Déployé en staging ? Déployé en production ? Validé par un utilisateur réel ? Si la réponse varie selon les développeurs ou selon les tickets, vous avez un problème de qualité invisible.
Une définition de "done" commune prend 30 minutes à écrire et élimine immédiatement les tickets "livrés" qui se retrouvent en production avec des bugs, les malentendus sur ce qui est réellement terminé, et les surprises lors des démonstrations client.
- Organisez une réunion de 30 minutes avec l'équipe technique.
- Posez la question : "Un ticket est 'done' quand ?" et listez toutes les réponses sans filtrer.
- Consolidez en une liste de 5 à 8 critères que tout le monde valide.
- Affichez cette liste dans votre outil de gestion de projet et appliquez-la dès le prochain sprint.
Vous n'avez pas besoin de comprendre chaque ligne. Vous avez besoin de voir les tendances. Les logs de production contiennent des informations que votre équipe ne vous remonte pas forcément : erreurs répétées, temps de réponse dégradés, tentatives d'accès suspectes, fonctionnalités utilisées vs fonctionnalités ignorées.
Si vous n'avez pas accès à un dashboard de monitoring lisible par un non-technique, c'est votre premier chantier. Des outils comme Sentry, Datadog ou même les alertes de base de votre hébergeur peuvent vous donner une vue de 5 minutes qui vaut plus que n'importe quel rapport hebdomadaire de l'équipe.
- Demandez à votre lead dev : "Quels outils de monitoring avons-nous en place ?" Si la réponse est "aucun", c'est urgent.
- Demandez un accès en lecture seule à Sentry (erreurs), à votre outil d'hébergement (CPU, mémoire, temps de réponse) et à Google Analytics ou équivalent (trafic).
- Bloquez 15 minutes chaque lundi matin pour consulter ces trois tableaux de bord.
- Notez les anomalies et posez des questions à votre équipe. Pas besoin de comprendre la cause technique : demandez l'impact et le délai de résolution.
Ce que ces 5 actions vous donnent — et ce qu'elles ne remplacent pas
Ces cinq actions vous donnent une visibilité réelle sur votre tech. Elles vous permettent de poser des questions informées, de détecter les problèmes avant qu'ils ne deviennent critiques, et de piloter votre équipe technique avec des données plutôt qu'avec des intuitions.
Ce qu'elles ne remplacent pas : les décisions d'architecture, le recrutement d'un développeur senior, l'évaluation de la qualité du code, la gestion de la dette technique profonde, et la définition d'une roadmap technique à 6 mois. Pour ces sujets, vous aurez besoin d'un regard expert — qu'il vienne d'un CTO externalisé ou d'un diagnostic ponctuel.
Ces actions sont le point de départ, pas l'arrivée. Elles vous permettent de comprendre où vous en êtes avant de décider si vous avez besoin d'aide externe — et de quelle aide exactement. Lisez aussi : ai-je besoin d'un CTO externalisé ?