Introduction
Il y a un moment, dans la vie d'une entreprise, où quelqu'un finit par poser la question qui dérange. « Au fait, si on changeait d'agence, on récupère quoi exactement ? » Silence dans la salle. Puis quelqu'un répond qu'on a bien un accès au back-office du site, et qu'il doit exister un compte Google Analytics quelque part.
C'est en général à ce moment précis qu'on découvre l'ampleur du problème.
La clause de réversibilité souffre d'une réputation détestable. On la perçoit comme un signal de défiance, une façon peu élégante de dire à un partenaire qu'on envisage déjà de le quitter avant même d'avoir commencé à travailler ensemble. C'est une lecture à contresens. Une clause de réversibilité bien écrite ne prépare pas une rupture : elle rend la relation saine, parce qu'elle repose sur un choix renouvelé plutôt que sur un verrouillage technique.
Ce qui suit n'est pas un rappel de droit des contrats. C'est un cadre opérationnel : ce qu'il faut inventorier, ce qu'il faut écrire noir sur blanc, comment séquencer une sortie, et quels pièges reviennent avec une régularité déprimante.
Ce que recouvre vraiment la réversibilité dans une prestation digitale
Définition opérationnelle : restituer, transférer, rendre exploitable
La réversibilité, c'est l'ensemble des obligations qui permettent à un client de reprendre en interne, ou de confier à un tiers, une prestation jusqu'ici assurée par un prestataire. Trois verbes, et le troisième est celui que tout le monde oublie.
Restituer : rendre ce qui appartient au client. Transférer : basculer les droits, les accès, les propriétés de compte. Rendre exploitable : livrer dans un état qui permet effectivement de continuer.
Un prestataire qui envoie une archive de 12 Go contenant l'intégralité du code source a techniquement restitué. Si personne ne peut redéployer ce code faute de savoir quelles variables d'environnement sont attendues, il n'a rien rendu d'exploitable. La différence entre les deux, c'est parfois six mois de retard et un budget de reprise multiplié par trois.
Réversibilité, portabilité, transférabilité : trois notions que l'on confond
La portabilité concerne les données : leur extraction dans un format lisible, indépendamment de l'outil qui les héberge. C'est une notion que le RGPD a popularisée pour les données personnelles, mais qui vaut bien au-delà.
La transférabilité concerne les droits : est-ce qu'une licence, un contrat, un abonnement peuvent changer de titulaire ? Beaucoup ne le peuvent pas, et c'est un sujet à traiter avant, pas après.
La réversibilité englobe les deux et y ajoute la dimension humaine : la documentation, la passation, l'accompagnement. C'est la seule des trois qui intègre le fait qu'une prestation digitale contient toujours du savoir non écrit.
Pourquoi le silence du contrat profite toujours au prestataire sortant
En l'absence de clause, on se retrouve à discuter d'obligations générales. Bonne foi, loyauté, obligation d'information. Des principes qui existent bel et bien, mais qui ont un défaut majeur : leur contenu concret se discute, et cette discussion prend du temps.
Or le rapport de force n'est pas symétrique. Le client qui veut partir est pressé, souvent parce que la relation s'est dégradée. Le prestataire, lui, n'a aucune raison de se hâter. Il détient les accès, il connaît l'architecture, il a le temps.
Écrire la clause, ce n'est pas se protéger d'un partenaire malveillant. C'est simplement retirer l'urgence de l'équation.
Les prestations concernées : hébergement, site, SEO, régie publicitaire, CRM, développement sur mesure
Toutes, en réalité. Mais avec des niveaux de risque très différents.
Une prestation de rédaction de contenus se reprend facilement : les articles sont en ligne, le brief est réutilisable. Un développement sur mesure, c'est une autre affaire. Entre les deux, on trouve le SEO, où la difficulté n'est pas technique mais mémorielle. Le référencement, c'est un empilement de décisions prises sur trois ans. Sans le journal de ces décisions, le repreneur va défaire des choses qui fonctionnent, simplement parce qu'il ne sait pas pourquoi elles sont là.
Le vrai risque : la dépendance construite sans intention de nuire
Les accès créés au nom du prestataire et jamais rétrocédés
Voilà le point qui mérite d'être dit clairement, parce qu'il change la façon d'aborder le sujet : dans l'immense majorité des cas, la dépendance ne résulte d'aucune stratégie.
Elle s'installe par commodité. Un chef de projet a besoin d'ouvrir un compte publicitaire un mardi après-midi pour lancer une campagne le mercredi. Il l'ouvre avec son adresse professionnelle, parce que c'est immédiat et que le client n'a pas encore validé la création d'une adresse dédiée. La campagne tourne, elle performe, personne n'y revient.
Trois ans plus tard, l'historique de conversion de ce compte vaut de l'or et il appartient à quelqu'un d'autre.
Le nom de domaine détenu par un tiers
C'est le cas le plus grave et, paradoxalement, l'un des plus fréquents. Le domaine a été réservé par le prestataire au moment de la création du site, souvent gratuitement, souvent en toute bonne foi.
Sauf que le titulaire du domaine, c'est la personne qui contrôle l'adresse. Les redirections, les enregistrements DNS, les e-mails professionnels. Perdre la main sur son domaine, ce n'est pas perdre un actif parmi d'autres : c'est perdre l'infrastructure sur laquelle reposent tous les autres.
La vérification prend deux minutes sur n'importe quel service de consultation Whois. Combien d'entreprises l'ont faite ? Peu.
Les comptes publicitaires et analytics ouverts sur un identifiant d'agence
Sur Google Ads, la nuance entre un compte détenu par le client et un compte administré depuis un centre multicompte échappe à beaucoup de monde. Dans le second cas, le lien de gestion se rompt sans difficulté. Dans le premier, si le compte a été créé par l'agence et n'a jamais été rétrocédé, on parle d'un transfert de propriété, ce qui suppose une coopération active.
Même logique côté Analytics. Un accès en lecture, ce n'est pas la propriété de la propriété. Et perdre un historique de mesure, c'est perdre la capacité de comparer.
Le code livré sans documentation, techniquement exact et pratiquement inutilisable
Le développement sur mesure produit une forme de dépendance particulièrement coriace. Le code est propre, il fonctionne, il a été livré conformément au contrat. Et il est illisible pour quiconque n'a pas participé à son écriture.
Pas par malice. Parce que documenter prend du temps, que ce temps n'a jamais été facturé, et qu'aucun développeur n'écrit spontanément un document destiné à celui qui le remplacera.
La connaissance non écrite : arbitrages, historique, raisons d'un choix
C'est la couche invisible, et souvent la plus précieuse.
Pourquoi cette page a-t-elle une URL bizarre ? Parce qu'une refonte de 2021 avait cassé les redirections et qu'on a fini par conserver l'ancienne structure pour ne pas perdre les liens entrants. Pourquoi ce module de paiement plutôt qu'un autre ? Parce que le précédent posait un problème avec la banque du client.
Rien de tout cela n'est écrit nulle part. Ça vit dans la tête de deux ou trois personnes. Et le jour où ces personnes ne travaillent plus sur le dossier, ça disparaît.
Cartographier les actifs avant de rédiger la clause
Construire l'inventaire contractuel des actifs numériques
On ne peut pas exiger la restitution de ce qu'on n'a pas identifié. L'inventaire précède la clause, toujours.
Concrètement : un tableau, une ligne par actif, et quatre colonnes qui font tout le travail. Nature de l'actif. Titulaire actuel. Titulaire cible en fin de contrat. Modalité de transfert.
L'exercice est fastidieux. Il est aussi révélateur : dans la moitié des cas, il fait apparaître des actifs dont plus personne ne se souvenait, et des titulaires qui ne sont pas ceux qu'on croyait.
Distinguer ce que l'on possède, ce que l'on loue, ce que l'on utilise sous licence
Trois régimes juridiques différents, trois traitements différents en fin de contrat.
Ce qu'on possède se restitue. Ce qu'on loue, on reprend l'abonnement à son nom, ou on l'abandonne. Ce qu'on utilise sous licence dépend entièrement des termes de cette licence, et personne ne les a lus.
Un thème premium acheté par l'agence sur une place de marché, avec une licence nominative non cessible : le client peut hériter du site, pas du droit d'utiliser le thème. Détail ? Pas vraiment. Le jour où une mise à jour de sécurité sort et que la licence est expirée, ça devient un vrai sujet.
Le cas des briques tierces et des licences non cessibles
Les prestations digitales modernes assemblent. Un site, c'est un socle, des extensions, des services externes, des connecteurs. Chaque brique a son propre régime.
La règle à poser dès l'inventaire : toute brique dont la licence n'est pas cessible doit être identifiée comme telle, et le contrat doit préciser ce qui se passe en fin de relation. Rachat par le client, remplacement par une alternative, ou acceptation du risque en connaissance de cause. Les trois réponses sont acceptables. Ne pas se poser la question ne l'est pas.
Annexer l'inventaire au contrat et prévoir sa mise à jour
Un inventaire figé à la signature perd sa valeur en quelques mois, parce qu'une prestation vivante crée des actifs en permanence.
La solution tient en une ligne dans le contrat : l'inventaire constitue une annexe, il est mis à jour à chaque revue périodique, et sa version la plus récente prévaut. Ajoutez la mise à jour de cette annexe à l'ordre du jour de vos points trimestriels. Cinq minutes, quatre fois par an. C'est le meilleur ratio effort/protection de tout ce document.
Rédiger la clause de réversibilité : les composantes indispensables
Déclencheurs : résiliation, non-renouvellement, défaillance, rupture anticipée
Une clause qui ne s'active que sur « résiliation » laisse passer plusieurs scénarios. Le non-renouvellement à l'échéance, par exemple, qui n'est pas une résiliation. Ou la cessation d'activité du prestataire.
Listez les déclencheurs de façon large : résiliation par l'une ou l'autre des parties, quel qu'en soit le motif ; non-renouvellement ; rupture anticipée ; défaillance, procédure collective, cessation d'activité ; changement de contrôle du prestataire.
Ce dernier point est sous-estimé. Une agence rachetée par un groupe, c'est une équipe qui change, des méthodes qui changent, parfois une relation qui n'a plus rien à voir avec celle qu'on avait signée.
Périmètre : la liste exhaustive de ce qui doit être restitué
Renvoyez à l'annexe d'inventaire plutôt que de tout réécrire dans le corps du contrat. Mais ajoutez une formule balai : « et de manière générale, tout élément produit dans le cadre de la prestation ou nécessaire à sa poursuite ».
Cette phrase attrape ce que l'inventaire a manqué. Il en manque toujours.
Formats de restitution : exploitables, ouverts, documentés
C'est ici que se joue la vraie différence entre une clause décorative et une clause utile.
Écrivez les formats. Pas « un format approprié », qui ne veut rien dire, mais : bases de données en export SQL ou CSV avec schéma relationnel documenté ; code source dans un dépôt versionné avec historique complet ; contenus rédactionnels en HTML ou Markdown ; visuels dans leurs fichiers sources éditables, pas seulement en formats aplatis.
Ce dernier point vaut d'être insisté. Recevoir des visuels au format image, c'est recevoir le résultat sans la matrice. La moindre modification suppose de tout refaire.
Délais et jalons : le calendrier de sortie
Un délai unique de restitution ne suffit pas, parce que les opérations sont séquentielles. Il faut des jalons.
Notification, puis remise de la documentation, puis transfert des accès, puis bascule, puis fin d'assistance. Chaque jalon avec sa date, calculée en jours à partir de la notification. Nous détaillons plus loin un séquencement type sur 90 jours.
Prix : réversibilité incluse ou facturée, et à quel tarif convenu d'avance
Deux options, aucune n'est mauvaise, mais il faut trancher à la signature.
Soit la réversibilité est incluse dans le prix de la prestation, et elle est alors comprise comme un livrable normal. Soit elle est facturée, et dans ce cas le tarif est fixé dès le départ, ainsi que le volume estimé.
Ce qu'il faut absolument éviter, c'est le silence, qui conduit à négocier le prix de sa propre sortie au moment où on a le moins de marge de manœuvre. Un devis de réversibilité présenté après la notification de rupture, ça se discute mal.
Obligation de résultat ou de moyens : l'arbitrage qui change tout
Sur ce point, la rédaction fait toute la différence en cas de litige.
Une obligation de moyens engage à mettre en œuvre les diligences nécessaires. En cas de problème, c'est au client de démontrer que le prestataire n'a pas fait le nécessaire. Une obligation de résultat engage sur l'atteinte du résultat lui-même : c'est au prestataire de prouver qu'il n'a pas failli.
Le bon arbitrage consiste à panacher. Résultat sur les éléments objectivables : transfert des accès, remise des livrables listés, respect des délais. Moyens sur ce qui dépend aussi du repreneur, notamment la qualité de la passation.
Sanctions et garanties : pénalités de retard, retenue de garantie, séquestre
Une obligation sans sanction reste une intention.
Les pénalités de retard fonctionnent bien à condition d'être calibrées : suffisamment dissuasives pour compter, suffisamment raisonnables pour ne pas être écartées comme manifestement excessives.
La retenue de garantie est l'outil le plus efficace. Une fraction du dernier règlement, conservée jusqu'à la validation de la réversibilité. Elle a le mérite d'aligner les intérêts sans conflit : le prestataire a une raison concrète de terminer proprement.
Le séquestre de code chez un tiers de confiance existe aussi. Réservez-le aux développements critiques : c'est un dispositif lourd, à réserver aux situations qui le justifient vraiment.
Propriété intellectuelle : cession des droits sur les livrables et sur le code
Point de vigilance majeur, et régulièrement bâclé : en droit français, la cession des droits d'auteur ne se présume pas. Payer une prestation créative ne vaut pas acquisition automatique des droits.
La clause de cession doit être explicite et détailler ce qu'elle couvre : droits de reproduction, de représentation, d'adaptation, de modification. Elle doit préciser son étendue territoriale, sa durée, et les supports concernés.
Sans cela, on se retrouve avec un site dont on est propriétaire des fichiers mais pas des droits d'exploitation. Une situation absurde, et pourtant assez courante.
Volet 1 — Le transfert des accès
Le principe fondateur : le client est propriétaire du compte, le prestataire y est invité
Un seul principe, et il résout à lui seul quatre-vingts pour cent des problèmes.
Tout compte relatif à l'activité du client est ouvert au nom du client, sur une adresse contrôlée par le client. Le prestataire y est ensuite ajouté comme utilisateur, avec les droits nécessaires à sa mission.
Cette règle a un coût : ouvrir les comptes proprement prend une demi-journée en début de mission, contre dix minutes en faisant au plus rapide. Cette demi-journée est le meilleur investissement du contrat. Elle transforme la fin de relation en simple révocation d'accès.
Les accès critiques à sécuriser dès la signature
Tous les accès ne se valent pas. Certains sont récupérables avec un peu de patience, d'autres sont des points de blocage absolus.
La hiérarchie : nom de domaine et zone DNS d'abord, hébergement et serveurs ensuite, puis dépôts de code, puis outils de mesure, puis comptes publicitaires et méthodes de paiement, puis back-offices et SaaS.
Si vous ne devez traiter qu'une chose cette semaine, traitez la première ligne.
Registrar et DNS, la première dépendance à neutraliser
Vérifiez le titulaire déclaré de votre domaine. Aujourd'hui, pas dans trois mois.
Si le titulaire n'est pas votre entité juridique, engagez le changement immédiatement. La procédure varie selon les bureaux d'enregistrement, elle est parfois un peu bureaucratique, elle n'est jamais insurmontable tant que la relation est bonne.
Séparez aussi, quand c'est possible, la gestion du domaine et celle de l'hébergement. Deux dépendances distinctes valent mieux qu'un point de défaillance unique : le jour où l'hébergeur pose problème, vous gardez la main sur l'adresse.
Hébergement, serveurs, dépôts de code
Le contrat d'hébergement doit être souscrit par le client. Le prestataire dispose d'un accès technique, pas de la propriété du contrat.
Pour les dépôts de code, l'organisation appartient au client, et les développeurs y sont membres. Là encore, la logique est identique : la structure appartient à celui qui la finance, les intervenants y sont invités.
Et l'historique du dépôt fait partie du livrable. Un code livré sans son historique de versions, c'est un code amputé de sa mémoire.
Google Analytics, Search Console, Tag Manager, Business Profile
Quatre outils, quatre modèles de propriété différents, et pas mal de subtilités.
Sur Analytics, ce qui compte c'est le compte de niveau supérieur, pas la propriété. Sur la Search Console, il faut distinguer le propriétaire vérifié des utilisateurs délégués, et vérifier par quel moyen la propriété a été validée : si c'est par un fichier ou une balise posée par le prestataire, la vérification peut sauter le jour où il retire l'élément.
Le profil d'établissement mérite une attention particulière, parce qu'il touche directement à la visibilité locale. Le client doit y être propriétaire principal, pas simple gestionnaire.
Régies publicitaires et méthodes de paiement
Sur les plateformes publicitaires, deux éléments à dissocier : l'accès au compte et le moyen de paiement associé.
Une carte bancaire d'agence enregistrée sur un compte publicitaire crée une dépendance financière autant que technique. Le jour de la sortie, il faut remplacer le moyen de paiement, et cette opération peut suspendre les campagnes si elle est mal préparée.
Anticipez : le moyen de paiement doit appartenir au client dès le départ, avec refacturation si le modèle économique le prévoit.
CMS, back-offices, outils SaaS et licences
Un compte administrateur au nom du client sur chaque outil. Pas un compte partagé, pas un compte générique dont personne ne connaît vraiment le mot de passe.
Pour les outils SaaS souscrits par l'agence dans le cadre de la mission, la question du transfert doit être posée dès la signature. Certains éditeurs autorisent le changement de titulaire, d'autres non. Le savoir avant permet d'organiser ; le découvrir après, c'est repartir de zéro sur l'outil concerné.
Gestion des identités : comptes nominatifs, gestionnaire de mots de passe, double authentification
Trois règles simples qui évitent des situations pénibles.
Des comptes nominatifs plutôt que des comptes partagés, ce qui permet de révoquer une personne sans casser l'accès des autres. Un gestionnaire de mots de passe partagé, avec des coffres distincts selon les niveaux de sensibilité. Et la double authentification rattachée à un numéro ou une application contrôlée par le client.
Ce dernier point est souvent négligé, avec des conséquences désagréables : un compte protégé par une double authentification liée au téléphone d'un salarié parti de l'agence, c'est un compte perdu. La récupération existe, elle prend des semaines.
La procédure de révocation : qui coupe quoi, dans quel ordre, et qui l'atteste
Couper les accès trop tôt bloque l'assistance. Trop tard, c'est laisser une porte ouverte.
La bonne pratique consiste à séquencer : rétrogradation des droits d'administration vers des droits de consultation à la bascule, puis révocation complète à la fin de la période d'assistance. Avec, à chaque étape, une trace écrite.
Le procès-verbal de transfert des accès
Un document simple, signé des deux parties, listant chaque accès transféré, la date, la personne réceptrice, et l'état de vérification.
Ce document a deux vertus. Il vaut preuve en cas de contestation. Et surtout, il oblige à vérifier réellement chaque accès plutôt qu'à supposer qu'ils fonctionnent. Combien de transferts se sont révélés incomplets au moment où on en avait besoin ? Beaucoup trop.
Volet 2 — La documentation
Documenter au fil de l'eau plutôt qu'à la sortie
Une documentation rédigée en fin de contrat est presque toujours mauvaise. Non par mauvaise volonté, mais parce que reconstituer trois ans de décisions en deux semaines est un exercice impossible.
La documentation produite dans ces conditions est descriptive : elle raconte ce qui existe. Or ce dont le repreneur a besoin, c'est de comprendre pourquoi ça existe.
Inscrivez donc la documentation dans le contrat comme un livrable récurrent, pas comme une obligation de sortie. Avec une revue de complétude à chaque échéance.
Le dossier technique : architecture, dépendances, environnements, procédures de déploiement
Le socle. Il doit contenir un schéma d'architecture lisible, la liste des dépendances avec leurs versions, la description des environnements et de leurs différences, les variables de configuration attendues, et la procédure de déploiement pas à pas.
Ajoutez-y les incidents notables et leur résolution. C'est la partie que personne n'écrit et que tout repreneur voudrait avoir.
Le dossier fonctionnel : parcours, règles de gestion, spécificités métier
Un logiciel finit toujours par contenir des règles bizarres. Une remise appliquée dans un cas précis, un statut qui bloque une action, un comportement différent pour une catégorie de clients.
Ces règles proviennent d'arbitrages métier réels. Elles ne se devinent pas dans le code, elles se documentent.
Le dossier data : structure des bases, exports, historiques, formats
Schéma relationnel commenté, description des tables, signification des champs qui ne sont pas explicites, procédure d'export testée.
Testée, oui. Une procédure d'export documentée mais jamais exécutée, c'est une procédure théorique. On découvre ses défauts au pire moment.
Le dossier stratégique en SEO et acquisition : arborescence, historique des optimisations, journal des redirections, netlinking
C'est le dossier le plus souvent absent, et celui dont l'absence coûte le plus cher.
Le journal des redirections mérite un mot particulier. Une redirection posée en 2022 après une refonte transmet toujours de l'autorité aujourd'hui. Un repreneur qui ne sait pas pourquoi elle existe peut la supprimer en faisant du ménage. Le trafic chute trois semaines plus tard, personne ne fait le lien, et on cherche la cause pendant des mois.
Même chose pour le netlinking : la liste des liens acquis, leur origine, leur date, les ancres utilisées. Sans cet historique, le repreneur reconstruit à l'aveugle.
Le registre des décisions : pourquoi tel choix, à quelle date, sur quel constat
Le document le plus simple à tenir et le plus précieux à recevoir.
Une ligne par décision structurante : la date, la décision, le constat qui l'a motivée, l'alternative écartée. Ça tient dans un tableur. Ça prend deux minutes par entrée.
Et ça vaut, en volume d'information utile, dix fois le dossier technique.
Critère d'acceptation : la documentation est bonne si un tiers compétent reprend sans vous
Le seul test qui vaille, et il est facile à écrire dans le contrat.
La documentation est réputée conforme si un professionnel du domaine, n'ayant pas participé au projet, peut déployer, modifier et exploiter la prestation en s'appuyant uniquement sur les documents remis.
Ce critère a un avantage décisif : il est vérifiable. On peut faire lire la documentation à un tiers avant la sortie et constater les manques pendant qu'il est encore temps de les combler.
Volet 3 — La période d'assistance
Durée réaliste selon la complexité : de quelques semaines à plusieurs mois
Une prestation simple se reprend en quelques semaines. Un système d'information sur mesure, avec ses intégrations et ses habitudes, demande plusieurs mois.
Trois repères qui fonctionnent bien en pratique. Prestation standardisée, site vitrine, contenus : trente jours suffisent. Prestation intégrée, SEO au long cours, boutique en ligne : soixante à quatre-vingt-dix jours. Développement sur mesure critique : six mois, avec une décroissance progressive du volume.
Mieux vaut prévoir large avec la possibilité de clôturer par anticipation que se retrouver court.
Volume d'heures, canaux, délais de réponse : cadrer plutôt que promettre
« Le prestataire assurera une assistance pendant trois mois » ne veut rien dire. Combien d'heures ? Par quel canal ? Sous quel délai ?
Chiffrez : un volume d'heures global ou mensuel, un canal identifié, un interlocuteur nommé, un délai de réponse selon la criticité. Et un mécanisme pour les heures au-delà du forfait, avec un tarif fixé d'avance.
Ce cadrage protège les deux parties. Le client sait ce qu'il obtient, le prestataire sait où s'arrête son engagement.
Le transfert de compétence : sessions de passation, réponses aux questions du repreneur
L'assistance ne se résume pas à répondre à des questions ponctuelles. Elle comprend des sessions structurées.
Prévoyez trois temps : une session de découverte générale, une session technique approfondie, une session dédiée aux points sensibles identifiés. Enregistrées, si possible, parce que le repreneur reviendra dessus.
Et prévoyez explicitement que le prestataire sortant répond aux questions du repreneur. Cela semble évident. Ça ne l'est pas quand les deux sont concurrents, et il vaut mieux l'avoir écrit.
La double présence temporaire pendant la bascule
Sur les prestations critiques, une période de recouvrement où les deux prestataires interviennent réduit considérablement le risque.
Elle coûte plus cher. Elle évite l'interruption de service, et sur certaines activités, une journée d'interruption coûte davantage que le mois de recouvrement.
Ce que l'assistance ne couvre pas : évolutions, correctifs, refonte déguisée
Précision indispensable, sans quoi la période d'assistance devient un gouffre.
L'assistance couvre : la transmission d'information, l'explication de l'existant, l'accompagnement de la bascule, la correction des anomalies imputables au transfert lui-même.
Elle ne couvre pas : les évolutions fonctionnelles, la correction d'anomalies préexistantes non signalées, l'adaptation du livrable aux outils du repreneur, la formation générale des équipes.
Cette liste évite une dérive classique où le repreneur découvre des choses à améliorer et les fait porter au sortant.
Facturation de la période et conditions de prolongation
Tarif fixé à la signature, conditions de prolongation prévues, plafond éventuel.
Une prolongation sans cadre, c'est une négociation en situation de dépendance. Autant l'écrire quand tout va bien.
Le calendrier de sortie : séquencer pour éviter l'interruption de service
J-90 : notification, activation de la clause, désignation des interlocuteurs
La notification formelle déclenche le compte à rebours. Elle s'accompagne de la désignation d'un référent de chaque côté, nommément.
Une réunion de lancement dans les dix jours, avec un ordre du jour simple : validation de l'inventaire, calendrier, points de vigilance identifiés.
Le ton de cette réunion détermine souvent le déroulement des trois mois qui suivent. Vaut la peine de la soigner.
J-60 : gel des évolutions, finalisation de la documentation, inventaire contradictoire
Le gel des évolutions est une mesure de bon sens : on ne documente pas un système qui bouge. Seules les corrections critiques et les mises à jour de sécurité restent autorisées.
L'inventaire contradictoire consiste à parcourir la liste des actifs ensemble, en vérifiant chaque ligne. C'est là qu'on découvre les oublis, et c'est encore le bon moment pour les traiter.
J-30 : transfert des accès, tests de reprise, répétition de la bascule
Les accès basculent, le procès-verbal est signé, et le repreneur teste.
La répétition de bascule est l'étape que tout le monde veut sauter pour gagner du temps. Ne la sautez pas. Déployer une copie du site sur un environnement de test à partir de la seule documentation, c'est le seul moyen de savoir si cette documentation tient debout.
Les problèmes découverts à ce stade se règlent tranquillement. Les mêmes problèmes découverts le jour de la bascule se règlent dans l'urgence, avec le site hors ligne.
J0 : bascule effective et vérification
Fenêtre planifiée sur une période creuse. Les deux équipes disponibles.
Après la bascule, une vérification systématique : les pages principales répondent, les formulaires fonctionnent, les e-mails partent, les paiements aboutissent, la mesure remonte.
Cette dernière vérification est régulièrement oubliée. On se réveille trois semaines plus tard en constatant un trou dans les données, impossible à combler rétroactivement.
J+30 à J+90 : assistance, surveillance des indicateurs, clôture
La période d'assistance court. En parallèle, une surveillance renforcée des indicateurs : trafic, positions, taux de conversion, erreurs serveur.
Fixez la fréquence des points de suivi. Hebdomadaire le premier mois, puis mensuel. Et prévoyez une réunion de clôture qui acte la fin de la réversibilité, déclenche la libération de la retenue de garantie, et solde la relation.
Le plan de retour arrière si la bascule échoue
Question qu'on préfère ne pas poser, et qu'il faut poser : que fait-on si ça ne marche pas ?
Le plan de retour arrière définit le seuil de déclenchement, le délai maximum pour décider, et la procédure de retour à l'état antérieur. Il suppose que l'environnement d'origine reste disponible pendant une période définie après la bascule.
On ne l'utilise presque jamais. Le jour où on en a besoin, on est très content de l'avoir écrit.
Les points de friction récurrents et comment les désamorcer
La rétention d'accès comme levier de négociation sur un impayé
Situation classique : le client conteste une facture, le prestataire suspend les accès. Chacun campe sur sa position, et l'entreprise se retrouve paralysée pour un différend de quelques milliers d'euros.
La parade tient en une clause : les obligations de réversibilité sont indépendantes de tout litige financier en cours. Le contentieux se règle devant le juge, pas en prenant l'outil de production en otage.
Symétriquement, la retenue de garantie protège le prestataire contre un client qui refuserait de payer une fois les accès récupérés. Équilibre.
Le prestataire injoignable ou en cessation d'activité
Le scénario le plus difficile, parce qu'aucune clause n'oblige quelqu'un qui a disparu.
Seule vraie protection : ne jamais dépendre d'un intermédiaire pour les accès critiques. Si le domaine, l'hébergement et les dépôts sont au nom du client, la disparition du prestataire reste douloureuse mais pas fatale.
Ajoutez un dépôt régulier des livrables chez le client. Une copie mensuelle du code et des données, stockée côté client. Ça ne coûte presque rien et ça change tout dans ce scénario.
Le désaccord sur la propriété du code et des développements spécifiques
Les positions s'affrontent souvent sur les briques réutilisables. Le prestataire a développé un module pour ce client, mais il l'a conçu pour le réutiliser ailleurs. Qui en est propriétaire ?
La réponse honnête : ça dépend de ce qui a été écrit. Et si rien n'a été écrit, ça se discute longuement.
Solution pragmatique : distinguer contractuellement le socle réutilisable, qui reste au prestataire et fait l'objet d'une licence d'utilisation perpétuelle au client, et les développements spécifiques, qui sont cédés. Chacun s'y retrouve, et surtout, chacun sait à quoi s'en tenir.
Les livrables restitués dans un format inexploitable ou tronqué
Formellement conforme, pratiquement inutile. C'est là que servent les spécifications de format évoquées plus haut.
Ajoutez une procédure de recette : le client dispose d'un délai pour vérifier et formuler des réserves motivées, le prestataire d'un délai pour y répondre. Sans procédure de recette, l'acceptation devient tacite et les défauts se découvrent trop tard.
La documentation produite à la hâte, formellement conforme et réellement vide
Trente pages qui décrivent l'évidence sans jamais expliquer le pourquoi. On coche la case, on ne transmet rien.
Le critère du tiers compétent règle la question, à condition de le mettre en œuvre. Prévoyez explicitement la possibilité de faire évaluer la documentation par un tiers, et prévoyez qui paie cette évaluation selon son résultat.
La perte de trafic ou de positions attribuée à la bascule
Trois semaines après le changement, le trafic baisse. À qui la faute ?
Sans données, la discussion est stérile. Avec des données, elle devient factuelle.
D'où l'intérêt d'un relevé contradictoire à J0 : positions sur les mots-clés suivis, trafic sur les principales pages, indicateurs de conversion, état de l'indexation. Un état des lieux signé par les deux parties.
Ce relevé ne prévient pas la baisse. Il permet de savoir si elle vient de la bascule, d'une mise à jour d'algorithme, ou d'une saisonnalité. Ce qui n'est pas rien.
Ce que le prestataire a, lui aussi, à y gagner
Une sortie propre comme argument commercial et signal de confiance
Retournons la perspective, parce qu'elle est trop souvent présentée à sens unique.
Un prestataire qui propose spontanément une clause de réversibilité détaillée envoie un signal fort. Il dit qu'il compte retenir ses clients par la qualité, pas par la difficulté à partir.
En rendez-vous commercial, cet argument porte. Il installe une crédibilité immédiate, parce que peu de concurrents le formulent.
Un cadre qui protège aussi le prestataire contre les demandes sans fin
Sans clause, une fin de contrat s'étire. Des demandes qui arrivent des mois après, des questions du repreneur auxquelles on répond par politesse, du temps non facturé qui s'accumule.
La clause délimite. Elle dit ce qui est dû, dans quel délai, pour quel prix. Passé ce cadre, le prestataire peut refuser sans passer pour un mauvais joueur.
Beaucoup d'agences découvrent ça en cours de route : la clause qu'elles redoutaient les protège au moins autant qu'elle protège leur client.
Le passage d'une relation de dépendance à une relation de valeur
Il y a une différence profonde entre un client qui reste parce qu'il ne peut pas partir et un client qui reste parce qu'il n'en a pas envie.
Le premier est un client fragile. Il attend l'occasion, il ne recommande pas, il négocie chaque renouvellement. Le second est un partenaire.
La réversibilité est ce qui permet de passer du premier au second. Elle oblige le prestataire à mériter sa place chaque année. C'est exigeant. C'est aussi ce qui fait tenir les relations longues.
Checklist opérationnelle à intégrer au contrat
Les clauses à faire figurer noir sur blanc
Une clause de réversibilité qui tient debout comporte au minimum : la définition des déclencheurs ; le périmètre de restitution avec renvoi à l'inventaire ; les formats attendus, précisément énumérés ; le calendrier avec jalons datés ; le régime de prix, inclus ou tarifé d'avance ; la qualification des obligations, résultat ou moyens, ligne par ligne ; les sanctions et garanties ; la cession de propriété intellectuelle explicite ; les modalités de la période d'assistance ; le principe de propriété client sur tous les comptes ; l'indépendance de la réversibilité vis-à-vis des litiges financiers ; la procédure de recette des livrables.
Douze points. Deux pages, correctement rédigées.
Les annexes obligatoires : inventaire des actifs, matrice des accès, plan de réversibilité
Trois annexes, et elles font le travail concret.
L'inventaire des actifs : nature, titulaire actuel, titulaire cible, modalité de transfert.
La matrice des accès : pour chaque outil, qui est propriétaire, qui a quels droits, comment se fait la révocation.
Le plan de réversibilité : le calendrier type, les livrables attendus à chaque jalon, les critères de validation.
Ces annexes se mettent à jour. Le contrat, lui, bouge rarement.
Les vérifications à mener chaque année pendant la vie du contrat
Une revue annuelle, une heure, quatre questions.
L'inventaire est-il à jour ? De nouveaux outils sont-ils entrés dans le périmètre sans être déclarés ? Les accès sont-ils toujours conformes au principe de propriété client, notamment après les mouvements de personnel ? La documentation couvre-t-elle les évolutions de l'année ?
Une heure par an. Comparée au coût d'une sortie mal préparée, c'est dérisoire.
Conclusion
Il faut peut-être renverser complètement la façon de présenter les choses.
Signer une clause de réversibilité, ce n'est pas préparer un divorce. C'est acheter la liberté de rester par choix. C'est se donner la possibilité de dire, chaque année : cette collaboration me convient, je la poursuis. Non pas parce que partir serait trop compliqué, mais parce que rester a du sens.
Cette liberté a un prix modeste. Quelques heures de cadrage à la signature, une revue annuelle, un peu de rigueur sur la création des comptes. À comparer aux six mois de reprise et au budget triplé d'une sortie non préparée, l'arbitrage n'est pas difficile.
Et pour les contrats déjà en cours, sans clause de réversibilité ? Il n'est jamais trop tard. On commence par l'inventaire, qui révèle presque toujours des dépendances insoupçonnées. On traite les points critiques par ordre de gravité, le nom de domaine en tête. On négocie un avenant, ce qui se fait sans difficulté quand la relation est bonne. Et si elle ne l'est pas, l'inventaire vous aura au moins appris où vous en êtes.
Chez FDSEO, l'audit des dépendances fait partie des premiers travaux menés sur un nouveau dossier. Cartographie des actifs, vérification des titulaires, identification des points de blocage, propositions de cadrage contractuel. Et quand il s'agit de reprendre une prestation laissée par un tiers, cette étape est le point de départ, parce qu'on ne construit rien de durable sur une base qu'on ne maîtrise pas.
