Un scénario plus fréquent qu’on ne le croit
Dans de nombreuses PME et ETI, l’applicatif métier central — celui qui gère les commandes, les stocks, la facturation ou la logistique — a été développé il y a plusieurs années par un développeur interne. Ce développeur connaît le code par cœur. Il est le seul à savoir pourquoi tel module fonctionne de cette façon, pourquoi telle intégration ERP a été câblée ainsi, pourquoi certaines données ne doivent jamais être modifiées directement en base.
Le problème : cette connaissance n’existe nulle part ailleurs. Pas de documentation. Pas de tests automatisés. Pas de procédure de reprise. Juste un homme ou une femme qui détient, seul, les clés de l’outil dont dépend l’activité quotidienne de 50, 100 ou 200 collaborateurs.
Dans le jargon technique, on appelle ça le bus factor — la réponse à la question : « Combien de personnes doivent être renversées par un bus pour que le projet s’arrête ? » Quand la réponse est 1, le risque est maximal.
Ce que ça coûte concrètement
Le coût d’une dépendance critique à un développeur unique se matérialise rarement d’un coup. Il s’accumule silencieusement, sous plusieurs formes.
Le coût de l’immobilisme d’abord : l’outil ne peut plus évoluer au rythme du métier. Chaque demande de modification passe par une seule personne, crée une file d’attente, ralentit les équipes. Les process s’adaptent à l’outil plutôt que l’inverse — et personne n’ose remettre en question ce fonctionnement par peur de « toucher à quelque chose qui marche ».
Le coût de la dette technique ensuite : sans mise à jour régulière, les versions de framework vieillissent, les failles de sécurité s’accumulent, les intégrations avec les outils tiers deviennent fragiles. Un applicatif Symfony 3 non maintenu en 2026 n’est pas juste obsolète — il est une bombe à retardement réglementaire, notamment au regard de NIS2.
Impact chiffré
Pour un acteur de la logistique ou du transport, chaque heure d’indisponibilité se chiffre en milliers d’euros de manque à gagner, sans compter l’impact client.
Le coût de l’arrêt enfin, le plus visible mais souvent le plus sous-estimé dans les scénarios de risque : une panne non anticipée sur un outil utilisé 24h/24 par les équipes opérationnelles, c’est un arrêt d’activité partiel ou total.
Les signaux d’alerte à ne pas ignorer
Certains signes avant-coureurs méritent une attention immédiate. Le premier et le plus évident : votre développeur interne parle de partir, cherche un nouveau poste, ou vous a déjà notifié son départ. La fenêtre pour réagir est alors de quelques semaines, pas de quelques mois.
D’autres signaux sont plus subtils. Une documentation inexistante ou obsolète. Des demandes d’évolution systématiquement repoussées « faute de temps ». Une infrastructure sans monitoring ni alertes automatiques. L’absence totale de tests automatisés, qui rend chaque modification risquée. Un processus de déploiement qui ne fonctionne que si c’est « lui » qui le fait.
« Si vous reconnaissez plusieurs de ces situations, le risque de continuité est réel — indépendamment du fait que votre développeur soit satisfait de son poste aujourd’hui. »
Besoin d’un audit de continuité ?
Identifions ensemble les risques sur votre applicatif métier
Ce qu’un audit technique de continuité permet de faire
Face à ce type de situation, la première étape n’est pas de recruter en urgence ni de lancer une refonte complète. C’est de cartographier précisément le risque avant d’engager le moindre budget.
Un audit technique de continuité applicative permet d’établir un état des lieux objectif : architecture du code, dépendances, versions, points de fragilité, absence de documentation, risques de sécurité identifiés. Il produit un livrable exploitable — pas un PowerPoint — qui chiffre le risque réel et propose une trajectoire d’amélioration priorisée.
C’est exactement ce qu’un acteur du secteur logistique a engagé après avoir identifié que deux de ses applicatifs métier critiques — utilisés par plus de 1 800 personnes par mois — reposaient intégralement sur un seul développeur interne, sans documentation ni tests. L’audit a permis de cartographier le code existant, d’identifier les dépendances critiques et de poser les bases d’une mission de TMA structurée, sans attendre un incident.
Le résultat : une continuité de service garantie, un développeur interne repositionné comme référent métier plutôt que remplacé, et une dette technique réduite progressivement sur 18 mois.
Votre applicatif métier repose sur une stack Symfony ou Laravel ? Discutons de votre situation et identifions les risques ensemble.
Externaliser la TMA : ce que ça change vraiment
La Tierce Maintenance Applicative (TMA) est souvent perçue comme une solution défensive — un filet de sécurité qu’on active quand quelque chose casse. C’est une erreur de cadrage.
Une mission TMA bien structurée, c’est d’abord une reprise de connaissance progressive du code existant par une équipe externe expérimentée. C’est ensuite la mise en place d’un monitoring proactif qui anticipe les pannes plutôt que de les subir. C’est enfin la création d’une documentation technique qui rend l’outil maintenable par plusieurs personnes, pas une seule.
Pour les PME et ETI dont l’applicatif tourne sur des stacks Symfony ou Laravel — des technologies robustes mais qui demandent une maîtrise réelle — ce type d’accompagnement représente un ticket mensuel nettement inférieur au coût d’un arrêt d’activité non planifié ou au recrutement en urgence d’un profil senior.
L’engagement est structurellement long : une fois la confiance établie et le code maîtrisé, le coût de changement de prestataire est élevé. C’est une relation qui se construit dans la durée, pas une prestation ponctuelle.
Experts en développement web et maintenance applicative. Nous accompagnons les PME et ETI dans la sécurisation et l’évolution de leurs outils métiers critiques.
