Un site qui ne se met plus à jour, une application interne que personne ne sait modifier, un prestataire qui ne répond plus aux e-mails. La situation est fréquente et rarement urgente au début : tout fonctionne encore. Elle le devient le jour où il faut changer quelque chose.
Avant de chercher qui pourra reprendre le travail, il y a une étape plus utile : récupérer ce qui vous appartient. Sans cela, n’importe quel intervenant repartira de zéro, et vous paierez cette reconstitution.
Les cinq éléments à récupérer en premier
- Le nom de domaine. Vérifiez à quel nom il est enregistré et qui reçoit les avis de renouvellement. Un domaine qui expire coupe le site et les e-mails d’un coup, souvent un vendredi soir.
- L’hébergement. Quel prestataire, quel contrat, payé par qui, et avec quel compte d’administration. Si la facture est au nom de votre ancien prestataire, vous ne contrôlez pas votre site.
- Les accès d’administration. Un compte à votre nom, avec les droits les plus élevés, sur le site comme sur l’outil. Pas un compte partagé dont le mot de passe circule depuis trois ans.
- Le code et la configuration, si l’outil a été développé pour vous. Demandez où il est stocké et comment y accéder. Un logiciel sans son code se remplace, il ne se répare pas.
- Une sauvegarde récente, testée. Une sauvegarde qu’on n’a jamais restaurée est une hypothèse, pas une sécurité.
Ces demandes sont légitimes et se formulent sans conflit : vous demandez l’inventaire de ce que vous payez. Un prestataire sérieux, même occupé, le fournit.
Ce qu’il ne faut pas faire tout de suite
Ne changez pas les mots de passe avant de savoir ce qui s’y connecte. Un site échange souvent avec d’autres services — paiement, envoi d’e-mails, formulaires, sauvegardes automatiques. Couper un accès au hasard casse un flux qui fonctionnait, et personne ne fait le lien trois jours plus tard.
Ne lancez pas non plus la refonte complète par réflexe. Le premier réflexe naturel — « on va tout refaire proprement » — coûte cher et efface l’existant avant de l’avoir compris. Souvent, une remise en état délimitée suffit pendant un an ou deux.
Quand une reprise est raisonnable, et quand elle ne l’est pas
Reprendre l’outil existant est le bon choix quand trois conditions sont réunies : les accès sont récupérables, l’outil rend encore le service attendu, et le problème est identifiable — une fonction cassée, une mise à jour bloquée, une évolution nécessaire.
À l’inverse, mieux vaut ne pas s’acharner quand le code est introuvable, quand la technologie employée n’est plus maintenue, ou quand le besoin a tellement changé que l’outil ne correspond plus à votre activité. Dans ces cas, le remplacement par une solution existante est souvent plus rapide et moins risqué qu’une reprise.
Cette décision — configurer, relier, remplacer ou développer — se prend après avoir regardé l’existant, pas avant. Une phase courte et facturée qui produit un état des lieux exploitable coûte moins cher qu’un projet lancé dans le brouillard.
Ce qui évite de revivre la situation
- Les comptes importants sont au nom de l’entreprise, avec une adresse e-mail qui survit au départ d’une personne.
- Un document court liste vos outils, qui les administre, ce qu’ils coûtent et à quelle date ils se renouvellent.
- Les sauvegardes sont vérifiées une fois, réellement, plutôt que supposées.
- Chaque prestation se termine par la remise des accès et d’une documentation minimale.
Ce n’est pas une question de méfiance envers les prestataires. C’est la même logique que de savoir où sont les clés de vos locaux.
Vous êtes dans cette situation ? Décrivez ce qui bloque à DevThis — ou voyez comment fonctionne le suivi de vos outils et de vos accès.