Récupérer le code source de son agence : guide Tunisie

Le scénario est devenu banal dans les PME tunisiennes. Vous avez confié votre site, votre application ou votre boutique à un développeur indépendant ou à une petite agence. Pendant deux ans, tout va bien. Puis les réponses se font rares. Le prestataire évoque "une période chargée", "des soucis personnels", "un nouveau projet prioritaire". Un jour, plus rien. Téléphone qui sonne dans le vide, WhatsApp en aperçu bleu, e-mails qui rebondissent.

Et vous réalisez : le code source, vous ne l'avez jamais eu. Le nom de domaine, vous ne savez pas chez quel registrar il est. Le mot de passe cPanel, c'est lui qui l'a. La base de données client, elle vit quelque part sur un VPS auquel vous n'avez jamais touché. Votre business tourne encore — pour combien de temps ?

Cet article est le playbook de reprise que nous appliquons chez Noqta dès qu'une PME nous contacte pour une "reprise d'agence". Il est rédigé pour le dirigeant, le directeur marketing ou le CTO non technique qui doit récupérer ce qui lui appartient — d'abord à l'amiable, ensuite par voie légale si nécessaire.

Avertissement. Les modèles juridiques cités ici (mise en demeure, dépôt de plainte) sont des points de départ pédagogiques, pas des conseils juridiques personnalisés. Toute action contentieuse doit être validée avec un avocat inscrit au barreau tunisien et, le cas échéant, un huissier de justice. Ce guide vous aide à arriver chez votre avocat avec un dossier déjà solide.

Étape 0 : respirer, puis dresser l'inventaire

Avant toute action, asseyez-vous trente minutes avec un cahier (oui, papier) et listez ce que votre activité utilise réellement. Beaucoup de dirigeants découvrent à ce moment-là qu'ils ne savent même pas ce qu'ils possèdent. Six familles d'actifs à séparer mentalement :

1. Le nom de domaine (monsite.tn, monsite.com). Géré chez un registrar : ATI pour les .tn, OVH, GoDaddy, Tunet, Genious ou autre pour les TLD internationaux.
2. L'hébergement : cPanel, Plesk, VPS DigitalOcean, serveur dédié OVH. C'est ici que tournent votre site et votre base de données.
3. Le code source : le dépôt Git (GitHub, GitLab, Bitbucket) si vous savez où il vit, plus les fichiers en production (public_html, /var/www).
4. La base de données : MySQL, MariaDB ou PostgreSQL. Contient vos clients, vos commandes, votre contenu. C'est généralement l'actif le plus critique.
5. Les comptes e-mail professionnels (contact@monsite.tn) : sur le cPanel, sur Google Workspace ou sur Microsoft 365.
6. Les services tiers : passerelle de paiement (Clictopay, Konnect, Paymee, Stripe), Google Analytics, Search Console, Meta Business Manager, Mailchimp, comptes publicitaires.

Pour chaque actif, posez-vous deux questions : "Suis-je propriétaire du compte ?" et "Ai-je les identifiants pour m'y connecter seul, aujourd'hui ?". Toute réponse "non" est une dépendance vis-à-vis de l'agence — donc un point de levier qu'elle peut utiliser contre vous.

Diagnostic : ce que vous possédez réellement vs ce qu'ils retiennent

La plupart du temps, la cartographie ressemble à ceci :

Faites le tableau pour votre situation. C'est votre carte de bataille. Tout ce qui est en colonne "cas critique" demandera soit une coopération forcée du prestataire, soit une reconstitution technique, soit une action légale.

Le protocole de récupération en 7 étapes

Voici la séquence que nous appliquons. Comptez deux à six semaines selon le degré de blocage et la réactivité de votre avocat.

Étape 1 — Constituer le dossier de preuves (jour 1 à jour 3)

Tout commence par la preuve. Sans pièces écrites, ni la pression amiable ni la pression légale ne fonctionne. Collectez et classez par date :

• Le contrat ou bon de commande initial (devis signé, e-mail d'accord, virement bancaire — n'importe quel acte prouve l'engagement).
• Les factures payées depuis le début de la relation. Elles établissent que vous êtes le client et que vous avez exécuté votre part.
• Les échanges e-mail/WhatsApp/Slack pertinents. Faites des captures d'écran horodatées, idéalement aussi des exports complets (Exporter le chat dans WhatsApp). Conservez les originaux : un huissier pourra constater l'authenticité.
• La dernière demande restée sans réponse : c'est votre point de départ pour caractériser la défaillance.
• Toute mention écrite de l'agence promettant livraison du code source, accès admin, ou transfert de propriété. Souvent dans une proposition commerciale ("livrables : sources complètes en fin de mission").

Stockez tout dans un dossier nommé dossier-reprise-AAAA-MM-JJ/ que vous sauvegardez à deux endroits (votre ordinateur + un cloud personnel).

Étape 2 — Lettre de demande amiable (semaine 1)

90 % des prestataires défaillants ne sont pas malveillants : ils sont dépassés. Une lettre claire et factuelle débloque souvent la situation sans frais juridiques. Elle doit être datée, signée, et envoyée par e-mail avec accusé de réception ET par courrier recommandé si vous avez l'adresse postale.

Modèle minimal à adapter :

Objet : Demande formelle de livraison des éléments contractuels — Projet [Nom du projet]

Monsieur / Madame [Nom],

Faisant suite au contrat / devis signé le [date] pour le projet [nom],
et à mes derniers messages restés sans réponse depuis le [date],
je vous demande la livraison sous quinze (15) jours calendaires des
éléments suivants, qui font partie intégrante de la prestation
facturée et payée :

1. Le code source complet du projet, sous forme d'archive ou via accès
   au dépôt Git (lecture + écriture).
2. La base de données complète (export SQL daté) ainsi que les
   fichiers utilisateurs (médias, uploads).
3. La documentation technique : procédure de déploiement, variables
   d'environnement, identifiants de services tiers.
4. Le transfert de propriété du nom de domaine [monsite.tn] vers un
   compte registrar à mon nom — code AUTH-INFO ou procédure équivalente.
5. Les accès administrateur (panneau d'hébergement, base de données,
   comptes e-mail) et la rotation des mots de passe partagés.

À défaut de réponse satisfaisante dans le délai imparti, je me
réserve le droit d'engager toute action utile, notamment une mise
en demeure par huissier de justice et, le cas échéant, le dépôt
d'une plainte au titre de l'article 242 du Code des obligations
et des contrats et de la loi 2004-63 relative à la protection
des données à caractère personnel.

Cordialement,
[Nom, qualité, raison sociale, adresse, téléphone]

Cette première lettre est utile même si vous ne pensez pas qu'elle aboutira : elle caractérise la défaillance et démarre le compteur juridique.

Étape 3 — Reprise technique de ce qui est déjà à vous (semaine 1-2, en parallèle)

Pendant que la pression amiable s'exerce, sécurisez immédiatement tout actif dont vous avez les clés. N'attendez pas la réponse de l'agence.

DNS et nom de domaine. Connectez-vous au registrar. Si le compte est à votre nom mais que vous n'avez plus le mot de passe : utilisez la procédure de réinitialisation par e-mail. Si l'e-mail de contact est celui de l'agence, contactez le support du registrar avec une pièce d'identité + un extrait Kbis/patente : la plupart (OVH, Cloudflare, Gandi) ont une procédure de récupération sur preuve de propriété. Pour les .tn gérés par l'ATI : ouvrez un ticket avec justificatif de votre raison sociale.

Hébergement. Si vous avez accès au cPanel/Plesk : faites immédiatement (1) un backup complet (Backup Wizard → Full Backup), téléchargez le .tar.gz chez vous, (2) un export SQL via phpMyAdmin (Exporter → Méthode personnalisée → Tout sélectionner), (3) un téléchargement FTP du dossier public_html ou /var/www. Vous venez de récupérer 90 % de votre actif numérique.

Comptes Google / Meta / Stripe. Connectez-vous, ouvrez la liste des administrateurs, promouvez votre propre compte au rôle Propriétaire (Owner) si vous ne l'êtes pas déjà, puis envisagez de rétrograder ou retirer l'agence. Attention : ne supprimez personne tant que vous n'avez pas vérifié que vous gardez l'accès facturation et propriété. Une mauvaise manœuvre sur Google Workspace peut suspendre vos e-mails.

Étape 4 — Reconstituer le code source quand vous ne l'avez pas (semaine 2-3)

C'est le scénario le plus douloureux : aucun dépôt Git, aucun ZIP, juste un site en production que personne ne maîtrise. Plusieurs voies, par ordre de préférence :

1. Téléchargement FTP/SSH des fichiers en production. Si vous avez ou récupérez l'accès cPanel, vous pouvez tirer tout le public_html chez vous. Ce n'est pas le dépôt Git originel, mais c'est le code qui tourne aujourd'hui. Pour un site WordPress, Magento ou PrestaShop, c'est largement suffisant pour qu'une autre agence reprenne la main.
2. Archive.org / Wayback Machine. Pour la partie statique (HTML, CSS, contenus), vérifiez les captures sur web.archive.org. Cela ne récupère pas le backend, mais peut sauver des pages contenu détruites entretemps.
3. Backup de l'hébergeur. La plupart des hébergeurs mutualisés tunisiens (Tunet, Hexabyte, Genious, OVH) conservent 7 à 30 jours de snapshots automatiques. Si la version actuelle est compromise ou incomplète, demandez la restauration d'une version antérieure. L'hébergeur ouvre généralement le ticket à condition que le compte soit à votre nom — d'où l'importance de l'étape 3.
4. Recompilation / rétro-ingénierie partielle. Pour une application JavaScript moderne (React, Vue, Next.js), le code transmis au navigateur est minifié mais récupérable. Des spécialistes (dont Noqta) peuvent reconstituer une base de code maintenable à partir du bundle de production, du HTML rendu et des appels API observés. Comptez 2 à 4 semaines selon la complexité.
5. En dernier recours : réécrire. Si rien ne peut être récupéré, partez de la documentation fonctionnelle existante (vos écrans, vos process, vos exports de données) et faites refaire l'application. Souvent moins long qu'on ne le craint — 6 à 12 semaines pour un site métier moyen — et l'occasion de moderniser une base déjà obsolète.

Étape 5 — Escalade juridique (semaine 3-4, si l'amiable échoue)

Si la lettre amiable est restée lettre morte, passez à la mise en demeure par voie d'huissier. C'est une étape peu coûteuse (quelques centaines de dinars), rapide, et qui change radicalement le rapport de force. L'huissier signifie le document en main propre ou par dépôt, et son procès-verbal vaut preuve devant le tribunal.

La mise en demeure reprend le contenu de votre lettre amiable, en y ajoutant :

• Le rappel des obligations contractuelles (clauses précises du devis ou du contrat).
• Le fondement légal : article 242 du Code des obligations et des contrats (exécution forcée des obligations contractuelles), articles 273 et suivants (responsabilité du débiteur pour inexécution).
• Le délai impératif : 8 ou 15 jours.
• L'annonce explicite des actions envisagées en cas de non-réponse : action en exécution forcée, action en dommages-intérêts, plainte pénale si rétention illicite de données à caractère personnel (loi 2004-63), saisine de l'Instance nationale de protection des données (INPDP).

Si l'agence détient des données personnelles de vos clients sans titre légitime ni votre instruction écrite, cela peut constituer un traitement non conforme au sens de la loi organique 2004-63. L'INPDP a déjà signalé plus de 330 organisations non conformes et transmis 260 dossiers au Procureur de la République, ce qui montre que le sujet n'est pas théorique.

Dans 70 % des cas que nous voyons, la mise en demeure suffit. L'agence ou son avocat répond dans la semaine, propose une remise des éléments, parfois en échange du solde des factures impayées (ce qui peut être négocié).

Étape 6 — Reconstruire vite et propre (semaine 4-6)

Quand vous avez le code, les données et les accès, ne perdez pas de temps à essayer de relancer le prestataire défaillant. Mobilisez immédiatement une nouvelle équipe pour :

• Auditer la sécurité du code récupéré : versions des frameworks, dépendances vulnérables, identifiants en dur, droits Unix sur le serveur.
• Rotation complète de tous les secrets (mots de passe DB, clés API Stripe/Konnect, jetons OAuth, clés SSH authorized_keys).
• Déploiement sur une infrastructure que vous contrôlez (VPS DigitalOcean, OVH, AWS, à votre nom, avec votre carte bancaire).
• Mise en place d'un dépôt Git dans votre organisation (github.com/votresociete) avec sauvegarde miroir hebdomadaire.
• Documentation minimale : un fichier README.md à la racine décrivant comment lancer, déployer et restaurer le projet. C'est ce document qui empêche la prochaine crise.

Étape 7 — Verrouiller pour qu'il n'y ait pas de "prochaine fois" (en continu)

La leçon coûte cher : ne la repayez pas. Les clauses contractuelles à exiger systématiquement de tout futur prestataire :

• Propriété intellectuelle : "Tous les droits patrimoniaux sur le code, les configurations et la documentation produits sont cédés au Client à compter du paiement de chaque facture." Sans cette clause, le code reste juridiquement la propriété du développeur, conformément aux principes du droit d'auteur tunisien.
• Dépôt Git client : "Le code source est poussé en miroir sur un dépôt Git appartenant au Client, à chaque release, dans un délai de 24h." C'est la clause d'escrow opérationnel — gratuite, technique, non négociable. Pour les projets sensibles, ajoutez un dépôt fiduciaire chez un tiers de confiance (escrow professionnel).
• Propriété des comptes : domaine, hébergement, Google Workspace, Stripe, tous au nom de la société cliente. Le prestataire reçoit des accès délégués nommés, jamais le rôle propriétaire.
• Plan de réversibilité : "En fin de mission ou en cas de résiliation, le Prestataire fournit sous 15 jours : code source à jour, base de données, documentation de déploiement, identifiants à rotation. Une indemnité forfaitaire de [X] DT par jour de retard est due au Client."
• Audit annuel : un audit technique annuel par un tiers indépendant (deuxième agence, consultant externe). Coût modeste, immense valeur de signal.

Le piège classique : la "convention de transfert" qui vous lie les mains

Quand l'agence se sait coincée, elle propose souvent un document amiable du type "protocole d'accord transactionnel" ou "convention de transfert". Lisez chaque ligne. Le piège standard contient une clause de renonciation à recours : "Le Client renonce à toute action, présente ou future, à l'encontre du Prestataire au titre du projet."

Ne signez pas ça. Le code récupéré peut contenir des dépendances vulnérables, des portes dérobées ou des données mal exportées que vous découvrirez seulement six mois plus tard. Si vous renoncez à tout recours aujourd'hui, vous perdez toute capacité d'action demain.

Acceptez le transfert, refusez la renonciation totale. Une formulation acceptable : "Le présent protocole vaut transfert des livrables énumérés à l'annexe 1. Il ne préjuge pas des recours du Client au titre de vices cachés, défauts de sécurité ou non-conformité réglementaire qui pourraient être ultérieurement constatés."

Faites relire avant signature par un avocat. Une heure de consultation peut vous éviter des années de blocage.

Trois autres pièges fréquents

"Je vous envoie un ZIP." Le ZIP arrive, vous remerciez, le dossier est clos. Trois mois plus tard, vous découvrez qu'il manque les migrations de base, les scripts de déploiement, ou la moitié des médias. Exigez toujours un test de déploiement : la nouvelle équipe doit pouvoir reconstruire l'application à partir de ce qui a été livré. Si elle n'y arrive pas, la livraison n'est pas faite.

"Le code est sur mon ordinateur personnel." Réponse acceptable : un dépôt Git poussé immédiatement. Réponse non acceptable : "Je vous l'enverrai quand j'aurai le temps." Aucun professionnel ne stocke du code client uniquement sur sa machine en 2026.

"Pour le domaine, je vais m'en occuper." Non. Exigez le code AUTH-INFO (chez OVH, Gandi, Cloudflare) ou la procédure de transfert ATI pour les .tn, et effectuez le transfert vous-même vers un compte registrar à votre nom. Tout intermédiaire ralentit, et un domaine "oublié" peut expirer ou être racheté par un concurrent.

Quand appeler du renfort

Vous pouvez exécuter ce protocole seul, surtout les premières étapes. Vous gagnez du temps (et souvent de l'argent) en déléguant quand :

• L'agence est complètement injoignable et le risque de coupure de service est imminent (domaine qui expire, hébergement impayé, certificat SSL en fin de vie).
• Vous découvrez que les données clients ont été exposées ou pourraient l'être : il faut un audit sécurité et, éventuellement, une démarche auprès de l'INPDP.
• Le code n'existe nulle part et il faut reconstituer depuis la production : c'est un travail spécialisé.
• Le différend financier dépasse quelques milliers de dinars et bascule en contentieux : il faut un avocat dès la rédaction de la mise en demeure.

Chez Noqta, nous accompagnons régulièrement les PME tunisiennes dans ce type de reprise. Notre offre "Reprise d'agence" couvre l'audit initial, la récupération technique, l'éventuelle reconstruction du code et la mise en place de la gouvernance contractuelle pour éviter la rechute.

Diagnostic gratuit de 30 minutes : nous regardons votre situation, identifions les actifs récupérables et vous remettons un plan d'action chiffré. Aucune obligation de poursuivre avec nous : si l'amiable peut fonctionner, nous vous le dirons.

Réserver un diagnostic Noqta →

Une dernière chose. Si vous lisez cet article avant d'être en crise — parce qu'un ami dirigeant vous a raconté son cauchemar — relisez l'étape 7. La vraie victoire, c'est de ne jamais avoir besoin des étapes 1 à 6. Cinq clauses contractuelles, un dépôt Git à votre nom, un audit annuel. C'est tout ce qui sépare une relation prestataire saine d'une prise d'otage silencieuse.