« Notre développeur est parti » : le protocole de récupération d'urgence en 7 étapes pour PME tunisiennes et marocaines

Le scénario revient toutes les semaines dans nos demandes entrantes. Le format est presque toujours le même : « Bonjour, notre développeur a quitté l'entreprise il y a trois mois — ou notre agence ne répond plus depuis le début de l'année — et nous ne savons plus comment maintenir notre site. Nous ne sommes même pas sûrs d'avoir le code source. Pouvez-vous nous aider ? »

Derrière cette phrase il y a presque toujours une PME tunisienne ou marocaine qui a fait confiance pendant des années à un freelance ou à une petite agence, qui a payé chaque facture sans poser de questions, et qui découvre du jour au lendemain qu'elle ne contrôle plus rien de son infrastructure numérique. Le nom de domaine est enregistré au nom de l'agence. L'hébergement est sur le compte personnel du développeur. Le code source vit sur un Bitbucket privé dont seul le développeur a les clés. Les sauvegardes — si elles existent — sont sur un Google Drive personnel inaccessible.

Cette situation est presque toujours réversible. Mais elle nécessite un protocole, dans l'ordre, sans improviser. Cet article est ce protocole — celui que nous appliquons chez Noqta sur ce type de mission, avec les commandes, les check-lists et les seuils de décision qui font la différence entre une récupération propre et une réécriture de zéro.

Pourquoi cette situation est si fréquente au Maghreb

Trois facteurs structurels rendent ce schéma particulièrement courant en Tunisie, au Maroc et en Algérie.

Le premier est la dépendance à un développeur unique. Une PME marocaine de 15 personnes qui paie un développeur 12 000 MAD par mois pour maintenir son site et ses outils internes ne va pas embaucher un second développeur en redondance. Le coût est trop élevé pour la valeur perçue. Quand le développeur part — démission, conflit, opportunité ailleurs — il part avec toute la connaissance opérationnelle de la stack.

Le deuxième est l'absence de procédures de transfert dans les contrats. Les contrats de prestation tunisiens et marocains pour la création de sites web sont rarement rédigés par un avocat spécialisé. Ils ne contiennent pas de clause de propriété du code, pas de clause de remise des accès, pas de clause d'escrow. Quand la relation se termine, il n'y a rien à invoquer juridiquement pour forcer le transfert.

Le troisième est la culture du « tout est dans la tête du dev ». La documentation écrite est l'exception, pas la règle. Quand le développeur part, la procédure de déploiement, les variables d'environnement, les scripts de cron, les intégrations tierces, les workarounds historiques — tout cela part avec lui. Reconstruire la connaissance opérationnelle est souvent plus long que reconstruire le code lui-même.

Ces trois facteurs se combinent. Le protocole de récupération doit traiter les trois, dans l'ordre, sinon il échoue.

Étape 1 — Inventaire documentaire (jour 1)

Avant toute action technique, faire l'inventaire complet de ce qui est encore connu. Cette étape est rarement faite parce qu'elle paraît administrative — mais sans elle, les étapes techniques tournent à vide.

Réunir dans un seul document :

• Factures des 3 dernières années : hébergeur, registrar, services cloud, abonnements logiciels (Patchstack, Cloudflare, Mailgun, etc.). Chaque facture indique un compte, donc un point d'accès potentiel.
• E-mails du développeur ou de l'agence contenant des identifiants, des URL administratives, des configurations, des liens vers des dépôts de code. Une recherche dans la boîte e-mail du dirigeant et de la personne qui suivait le projet (CTO, marketing, IT) ramène souvent 70 % de ce qui est nécessaire.
• Contrats signés avec le développeur ou l'agence. Identifier toute clause relative à la propriété intellectuelle, au transfert des accès, à la confidentialité, à la fin de contrat.
• Captures d'écran ou exports d'outils internes qui montreraient l'architecture : tableau Trello, document Notion, espace partagé Google Drive, Slack, WhatsApp d'équipe.
• Liste des utilisateurs qui interagissent encore avec le site : qui se connecte au back-office, qui reçoit les notifications de commande, qui modifie le contenu.

Le livrable de l'étape 1 est un document récapitulatif d'une à trois pages qui liste tout ce qui est connu, tout ce qui est inconnu, et tout ce qui est suspect (un compte dont l'existence est attestée mais dont les identifiants ne sont pas retrouvés).

Étape 2 — Récupération du nom de domaine (jours 1-2)

Le nom de domaine est l'asset le plus critique. Sans lui, le site n'est pas accessible et toute migration est inutile. Sans contrôle du domaine, le développeur sortant ou l'agence peut techniquement faire pointer le site ailleurs.

Vérifier d'abord l'enregistrement WHOIS du domaine :

whois votre-domaine.tn
whois votre-domaine.ma
whois votre-domaine.com

Le résultat indique le registrar (l'entreprise chez qui le domaine est enregistré : Tunisie Telecom, Genious Communications, GoDaddy, OVH, Gandi) et — si le domaine n'est pas anonymisé — le propriétaire enregistré.

Trois cas se présentent :

Cas A — domaine enregistré au nom de la PME. Vous êtes propriétaires. Récupérez l'accès au compte registrar via la procédure de réinitialisation de mot de passe sur l'adresse e-mail de contact. Si l'adresse de contact est l'adresse personnelle du développeur, contactez le support du registrar avec la pièce d'identité du dirigeant et une preuve de propriété pour faire changer l'adresse de contact.

Cas B — domaine enregistré au nom de l'agence ou du développeur. Demandez formellement le transfert. Pour les domaines .tn, l'ATI (Agence Tunisienne d'Internet) traite les transferts entre titulaires sur dossier. Pour les domaines .ma, l'ANRT (Agence Nationale de Réglementation des Télécommunications) via le réseau Mariwan-Dot.ma joue le même rôle. Pour les domaines .com chez un registrar international, la procédure de transfert nécessite la coopération du titulaire actuel — sans coopération, le recours est juridique.

Cas C — domaine anonymisé ou inaccessible. Identifier le registrar via le WHOIS et entamer la procédure de litige (UDRP pour les TLD génériques, procédures spécifiques pour les ccTLD). Cette voie peut prendre 2 à 4 mois.

Pendant que la procédure avance, sécuriser le domaine actuel contre toute modification : verrouillage du transfert, alerte en cas de modification DNS.

Étape 3 — Récupération de l'hébergement et des serveurs (jours 2-4)

L'objectif est de reprendre le contrôle de la machine qui sert le site, ou — si ce n'est pas possible — de répliquer son contenu sur une infrastructure que vous contrôlez.

Identifier l'hébergeur via une combinaison de méthodes :

# Identifier l'IP du serveur
dig +short votre-domaine.tn
 
# Identifier le propriétaire de l'IP
whois <ip-trouvée>
 
# Identifier l'éventuel CDN
curl -I https://votre-domaine.tn
# Chercher des headers comme cf-cache-status (Cloudflare), x-bunkerweb-* (BunkerWeb), etc.

Le résultat oriente vers l'hébergeur (DigitalOcean, OVH, AWS, Tunisie Telecom Cloud, Maroc Telecom Cloud, etc.). Récupérer ensuite l'accès au compte hébergeur via les mêmes méthodes que pour le registrar : factures pour identifier le compte, réinitialisation de mot de passe, support de l'hébergeur avec preuve de propriété si l'adresse e-mail est inaccessible.

Si l'accès au compte est récupéré, prendre immédiatement :

• Une sauvegarde complète du serveur (image disque, dump de base de données, copie de /var/www/).
• Une liste des utilisateurs SSH actifs avec leurs clés publiques (/etc/passwd, /home/*/.ssh/authorized_keys).
• Une liste des tâches cron (crontab -l pour chaque utilisateur, contenu de /etc/cron.d/).
• La configuration du serveur web (/etc/nginx/, /etc/apache2/) et des certificats SSL (/etc/letsencrypt/ ou autres).

Si l'accès n'est pas récupérable, deux options : (a) demander au support de l'hébergeur une copie des données moyennant preuve de propriété — possible mais lent ; (b) répliquer le site visible publiquement (front-end, contenu indexé, fonctionnalités publiques) sur une nouvelle infrastructure et reconstruire la partie privée à partir des sauvegardes éventuelles trouvées à l'étape 1.

Étape 4 — Récupération du code source (jours 3-6)

Le code source vit habituellement dans un dépôt Git privé : GitHub, GitLab Cloud, Bitbucket, ou un serveur Git auto-hébergé. Identifier l'emplacement via :

• Les e-mails du développeur (notifications de commits, invitations à rejoindre un dépôt).
• Les fichiers de configuration sur le serveur (.git/config dans /var/www/, composer.json qui référence un dépôt privé).
• Les factures (un dépôt GitHub Teams coûte 4 USD par mois, un GitLab Premium 19 USD ; les factures sont retrouvables).

Trois cas :

Cas A — dépôt sur un compte que vous pouvez réclamer (organisation GitHub/GitLab de l'entreprise). Récupération directe via réinitialisation de mot de passe et procédure de transfert d'organisation.

Cas B — dépôt sur le compte personnel du développeur. Demander formellement le transfert. En cas de refus, deux options : reconstruire le code à partir de la copie présente sur le serveur de production (/var/www/ contient presque toujours le code, sans l'historique Git mais avec l'état le plus récent), ou invoquer la clause contractuelle de propriété intellectuelle si elle existe.

Cas C — dépôt sur un serveur Git auto-hébergé par l'agence (GitLab CE chez l'agence). Demander l'accès. Sans coopération, reconstruire à partir du serveur de production.

Pour la reconstruction à partir du serveur de production :

# Sur le serveur récupéré, depuis /var/www/votre-site
git init
git add -A
git commit -m "Reconstruction initiale depuis l'état de production"
git remote add origin https://github.com/votre-org/votre-site.git
git push -u origin main

Cette reconstruction perd l'historique Git (les anciens commits, les branches en cours, les messages de commit) mais préserve l'intégralité du code source actuel. Pour la plupart des PME, c'est suffisant pour reprendre la maintenance.

Étape 5 — Récupération des comptes critiques tiers (jours 4-7)

Au-delà du code et de l'hébergement, le site dépend habituellement de plusieurs services tiers : passerelles de paiement (Paymee, Konnect, ClicToPay, Stripe, PayPal), services e-mail (Sendinblue, Mailgun, SendGrid), analytics (Google Analytics, Plausible), CDN (Cloudflare), monitoring (UptimeRobot, Sentry), comptes sociaux (Facebook Business, Google My Business).

Pour chaque service :

• Identifier le compte via les factures et les e-mails.
• Récupérer l'accès via la procédure de réinitialisation.
• Faire tourner les clés API immédiatement après récupération (le développeur sortant peut techniquement encore les utiliser même sans accès au compte).
• Ajouter un utilisateur administrateur appartenant à la PME (compte e-mail professionnel), pas seulement le dirigeant individuellement.

L'erreur classique à cette étape : se contenter de récupérer l'accès sans faire tourner les clés. Une clé API Stripe non rotée reste utilisable par celui qui la connaît, même si l'accès au tableau de bord Stripe a été retiré.

Étape 6 — Audit de sécurité post-récupération (jours 5-10)

Le développeur sortant a-t-il laissé une porte dérobée volontairement (web shell, compte administrateur caché, cron de récupération d'accès) ou involontairement (clés SSH dans authorized_keys, abonnement Patchstack sur son compte personnel) ? L'étape 6 répond à cette question.

Actions concrètes :

• Audit des comptes administrateurs : pour WordPress, exécuter wp user list --role=administrator ; pour Magento, vérifier la table admin_user ; pour Laravel, vérifier la table des utilisateurs avec rôle admin. Désactiver ou supprimer tout compte non identifié.
• Audit des clés SSH : sur le serveur, parcourir /home/*/.ssh/authorized_keys et la racine /root/.ssh/authorized_keys. Retirer toute clé non identifiée.
• Audit des tâches cron : crontab -l pour chaque utilisateur, contenu de /etc/cron.d/. Supprimer toute tâche dont l'objectif n'est pas documenté.
• Recherche de portes dérobées web : sur un site WordPress ou Magento, exécuter la commande de détection d'obfuscation (grep -rE "eval\(base64_decode|gzinflate" /var/www/). Sur tout type de site, scanner avec Wordfence, Patchstack ou Sucuri.
• Rotation complète des identifiants : mots de passe administrateur, clés SSH, clés API, identifiants de base de données, identifiants SMTP, secrets OAuth.

L'objectif est de ramener le système à un état où la seule personne disposant d'un accès est la PME et le nouveau prestataire chargé de la maintenance.

Étape 7 — Mise en place de la nouvelle discipline (jours 7-15)

Une fois le contrôle repris, l'erreur à éviter est de reproduire les mêmes faiblesses avec le prochain prestataire. L'étape 7 consiste à mettre en place les disciplines qui rendent la prochaine séparation indolore.

Cinq mesures concrètes :

1. Miroir Git client : tout dépôt de code est mirroré en continu vers un dépôt appartenant à la PME (GitHub Organization, GitLab Cloud sous compte client, Bitbucket sous compte client). Cette disposition figure dans tout nouveau contrat.
2. Propriété des comptes critiques : registrar, hébergeur, services cloud, comptes Google Workspace, comptes de paiement — tous au nom de la PME, avec le prestataire en utilisateur délégué (admin sous-compte), jamais en propriétaire.
3. Vault d'identifiants partagés : Bitwarden Teams, 1Password Business ou Vaultwarden auto-hébergé — tout identifiant partagé y est stocké, jamais en clair dans Slack, WhatsApp ou un e-mail.
4. Sauvegardes vérifiées trimestriellement : test de restauration tous les 90 jours sur un environnement de bac à sable, temps de restauration mesuré, plan d'escalade si supérieur à 4 heures.
5. Audit semestriel des accès : qui peut se connecter à quoi, depuis quand, pour quelle raison. Toute personne dont le rôle n'est plus actif voit ses accès retirés.

Ces cinq mesures coûtent ensemble moins de 200 EUR par mois pour une PME tunisienne et changent radicalement la dynamique de pouvoir entre client et prestataire.

Quand le protocole ne suffit pas

Trois cas où le protocole de récupération en 7 étapes doit être complété par d'autres mesures.

Cas 1 — contentieux ouvert avec l'agence sortante. Le protocole technique avance en parallèle de la procédure juridique. Avant toute action sur les comptes ou les serveurs, documenter l'état initial (captures d'écran, exports, attestation d'huissier si l'enjeu est significatif). L'objectif est de pouvoir prouver l'état des choses au moment de la séparation.

Cas 2 — données chiffrées ou détenues en otage par le prestataire. Si le prestataire a chiffré la base de données ou un volume critique et refuse de fournir la clé, c'est un cas d'incident de sécurité grave. La voie juridique (plainte pour entrave au fonctionnement d'un système de traitement automatisé de données — article 199 ter du Code pénal tunisien) doit accompagner la voie commerciale.

Cas 3 — application mobile sans accès aux certificats de publication. Pour iOS, sans l'accès au compte Apple Developer et au certificat de distribution, l'application existante reste publiée mais ne peut plus recevoir de mise à jour. Pour Android, sans le keystore de signature, même chose. La récupération nécessite une coopération de l'éditeur sortant ou un republication sous un nouveau nom (perte des avis, du référencement, des téléchargements existants).

Pour ces cas, le protocole de récupération doit être complété par une assistance juridique dès l'étape 1 et un budget de contingence pour reconstruction partielle si nécessaire.

Ce que Noqta fait différemment

Notre offre PMaaS inclut le protocole de récupération en 7 étapes en tant que mission ponctuelle pour les nouveaux clients qui héritent d'une situation complexe. Nous le couplons systématiquement à la mise en place de la nouvelle discipline (étape 7) pour que le client n'ait pas à refaire cette mission dans 18 mois.

Pour les clients déjà sous gestion PMaaS, ces disciplines sont natives dès le jour 1 : tout dépôt est mirroré, tout compte est au nom du client, tout identifiant est en vault partagé, toute sauvegarde est testée trimestriellement, tout accès est audité semestriellement. Le scénario « notre développeur est parti » devient un non-événement opérationnel — un nouveau développeur reprend le dépôt mirroré, change les mots de passe via le vault, et continue.

Lectures connexes : la clause d'escrow de code source pour MENA, le manuel d'audit fournisseur, le guide de migration Laravel 11 vers Laravel 13, et la détection en 10 minutes des portes dérobées WordPress.