[Temps de lecture : 8 minutes]
Lundi matin, 9h. Vous essayez de joindre votre agence web pour signaler un bug. Le téléphone sonne dans le vide. Le site de l’agence affiche une page blanche. Leur profil LinkedIn n’a plus été actif depuis 3 mois.
Votre application est en production, utilisée par 30 personnes au quotidien. Pas de documentation, pas d’accès au code source, pas de plan B. Le serveur tourne encore… mais pour combien de temps ?
Si vous vivez cette situation, cet article est votre feuille de route. Pas de théorie – 5 étapes concrètes, dans l’ordre, pour sécuriser votre système et reprendre le contrôle.
1 sur 3
PME concernées par une perte de prestataire
5-10K€
coût estimé par JOUR d’interruption
+50-100%
surcoût d’un changement non préparé
80K€+
devis de refonte inutile sans audit préalable
D’abord : pas de panique
La disparition d’un prestataire IT est un scénario plus courant qu’on ne le croit. L’agence ferme, le freelance part à l’étranger, la SSII perd le développeur qui connaissait le projet. Les raisons varient, mais les conséquences sont toujours les mêmes :
- Plus personne ne comprend le code
- Les accès serveur, hébergement et code source sont incertains
- Les bugs ne sont plus corrigés
- Un autre prestataire propose une « refonte complète » à 80–150K€
- Le dirigeant se demande si tout est perdu
La bonne nouvelle : dans 80% des cas que Struxis accompagne, la refonte est évitable. Le système est récupérable, le code est maintenable, et un nouveau prestataire peut reprendre la suite sans tout recommencer. Mais il faut agir vite et dans le bon ordre.
Etape n°1 – Sécuriser les accès (immédiat)
⏱️ Délai : 24–48 heures – urgence absolue
C’est la première chose à faire, avant toute réflexion stratégique. Si le prestataire détenait les accès, ils peuvent disparaître avec lui.
CHECKLIST URGENTE ☐ Serveur / hébergement : vérifier que le contrat est au nom de VOTRE société, pas de l’agence ☐ Nom de domaine : vérifier la propriété et le renouvellement (OVH, Gandi, etc.) ☐ Code source : vérifier si vous avez accès au repository Git (GitHub, GitLab, Bitbucket) ☐ Base de données : sauvegarder intégralement (dump SQL) dès que possible ☐ Emails / DNS : vérifier que les enregistrements DNS sont accessibles ☐ Comptes tiers : lister tous les services utilisés (Stripe, Mailchimp, API, etc.) ☐ Mots de passe : changer tous les accès dont le prestataire avait connaissance |
⚠️ Attention : si le contrat d’hébergement est au nom de l’agence disparue, contactez l’hébergeur immédiatement avec votre extrait Kbis et les preuves de propriété du projet (contrat signé, factures). La plupart des hébergeurs (OVH, o2switch, Scaleway) ont des procédures pour ces cas. |
Etape n°2 – Faire un état des lieux technique (J+2 à J+5)
⏱️ Délai : 3 jours – audit de reprenabilité
Une fois les accès sécurisés, il faut savoir dans quel état se trouve le système. Pas avec des suppositions – avec un audit factuel.
L’audit de reprenabilité répond à 3 questions clés :
Le code est-il maintenable ?
Qualité du code, présence de tests, documentation, lisibilité. Score de reprenabilité /10.
L’architecture est-elle saine ?
Technologies utilisées, dépendances, vulnérabilités, dette technique. Risques structurels.
Faut-il tout refaire ?
Analyse coût/bénéfice : évolution progressive vs. refonte. Le verdict objectif.
Struxis observe que dans 80% des cas, la refonte est disproportionnée. Le code est souvent « moyen mais maintenable » – score 5-7/10. Suffisant pour continuer à évoluer sans tout jeter.
Etape n°3 – Sélectionner un nouveau prestataire (J+5 à J+15)
⏱️ Délai : 5–10 jours – sélection accélérée
C’est la décision la plus critique. Le reflexe naturel est de signer avec le premier prestataire disponible pour « éteindre l’incendie ». C’est précisément comme ça qu’on se retrouve dans 6 mois avec un deuxième prestataire problématique.
Le nouveau prestataire doit répondre à un critère spécifique que Struxis considère comme non négociable : la capacité à reprendre du code existant. Beaucoup de développeurs savent coder from scratch. Très peu savent lire, comprendre et améliorer le code de quelqu’un d’autre. C’est une compétence fondamentalement différente.
CRITÈRES CLÉS DE SÉLECTION (EN CONTEXTE DE REPRISE) ✅ Références vérifiables de reprise de code existant (pas seulement du développement neuf) ✅ Maîtrise de la stack technique actuelle (PHP/Laravel, Node, React, etc.) ✅ Engagement à documenter le code existant avant de le modifier ✅ Méthodologie : capacité à travailler par lots avec recette structurée ✅ Clauses contractuelles obligatoires : propriété du code, réversibilité, SLA, code source accessible à tout moment |
💡 Le conseil Struxis : ne signez jamais un contrat de reprise sans clause de réversibilité explicite. C’est la leçon n°1 de la situation que vous venez de vivre. Si vous ne pouvez pas récupérer votre code à tout moment, vous reproduirez la même dépendance.
Etape n°4 – Piloter la reprise (mois 1 à 3)
⏱️ Délai : 2–3 mois – phase de stabilisation et rattrapage
Le nouveau prestataire est à bord. La tentation est de lui demander immédiatement toutes les évolutions qui attendaient depuis des mois. C’est une erreur. La reprise doit suivre un ordre précis :
Phase | Objectif | Activités | Durée type |
Sem. 1–2 | Documentation | Le prestataire lit, comprend et documente le code existant AVANT de toucher quoi que ce soit | 2 semaines |
Sem. 3–6 | Corrections urgentes | Bugs critiques, failles de sécurité, problèmes de performance. Pas de nouvelles features. | 1 mois |
Sem. 7–12 | Rattrapage | Évolutions en attente, livrées lot par lot avec tests non-régression à chaque livraison | 6–8 semaines |
La règle de Struxis : le nouveau prestataire ne touche pas une ligne de code avant d’avoir documenté ce qu’il a lu. Si cette phase est skipée, on reproduit exactement la même situation de dépendance.
Etape n°5 – Blinder pour que ça n’arrive plus jamais
⏱️ Délai : Mise en place progressive – protection long terme
Une fois la crise passée, il faut tirer les leçons et mettre en place les protections pour que cette situation ne se reproduise jamais. Struxis recommande systématiquement les 7 mesures suivantes :
LES 7 PROTECTIONS À METTRE EN PLACE 1. Le code source est hébergé sur un repository dont VOUS êtes propriétaire (GitHub / GitLab à votre nom) 2. Le contrat d’hébergement est au nom de votre société, pas du prestataire 3. Le nom de domaine est enregistré à votre nom, avec renouvellement automatique 4. Une documentation technique minimale existe (archi, modules, dépendances, accès) 5. Le contrat prestataire inclut une clause de réversibilité et la propriété du code 6. Les sauvegardes sont automatiques, vérifiées et stockées sur un compte qui vous appartient 7. Tous les mots de passe sont dans un gestionnaire (1Password, Bitwarden) que vous contrôlez |
📋 Checklist Struxis gratuite : ces 7 points constituent la « checklist de souveraineté numérique » que Struxis recommande à tous ses clients, dès le premier jour de mission. Si vous répondez « non » ou « je ne sais pas » à l’un de ces points, votre situation est fragile.
Timeline récapitulative : du jour 0 au mois 3
Délai | Étape | Actions clés | Résultat |
J0–J2 | 🔒 Sécuriser | Récupérer accès, sauvegarder code + BDD, changer mots de passe | Continuité de service assurée |
J2–J5 | 🔍 Auditer | Audit de reprenabilité, score /10, recommandation évolution vs. refonte | Décision éclairée |
J5–J15 | 🤝 Sélectionner | Appel d’offres ciblé, critères de reprise, négociation clause réversibilité | Nouveau prestataire signé |
M1–M3 | 🛠️ Reprendre | Documentation → corrections urgentes → évolutions par lots | Système stabilisé + évolué |
Continu | 🛡️ Blinder | 7 protections mises en place pour éviter la récidive | Souveraineté numérique |
Combien coûte un plan d’urgence vs. une refonte panique
Plan d’urgence Struxis
Sécurisation + audit + sélection + pilotage reprise
20 à 35K€
Délais : 2 – 3 mois
Refonte panique
Tout refaire from scratch avec un prestataire choisi dans l’urgence
80 à 200K€
Délai : 6-12 mois
Economie
Budget économisé + continuité de service préservée
60-165K€
ROI : 3 à 5x
La vraie question à se poser maintenant
Si votre prestataire disparaissait demain matin, seriez-vous prêt ? Avez-vous le code source ? Savez-vous où est hébergé votre site ? Avez-vous une documentation technique, même minimale ?
Si vous avez répondu « non » ou « je ne sais pas » à l’une de ces questions, votre situation est fragile. Pas urgente, mais fragile. Et la différence entre une situation fragile et une crise, c’est un lundi matin où le téléphone sonne dans le vide.
« Le meilleur moment pour préparer un plan d’urgence, c’est quand on n’en a pas besoin. Le pire moment, c’est quand on est déjà dans l’urgence. »
Votre prestataire a disparu ?
Struxis peut intervenir en 48h pour sécuriser vos accès, auditer la reprenabilité et piloter la transition vers un nouveau prestataire.
