Personne ne signe un contrat d'externalisation en pensant à la rupture. C'est pourtant le meilleur moment pour y penser. Au jour de la signature, vous avez tout le pouvoir de négociation. Le jour où vous voudrez partir, vous n'en aurez plus aucun.

La réversibilité, c'est votre capacité à reprendre une activité externalisée, ou à la confier à quelqu'un d'autre, sans rupture de service et sans perte de savoir-faire. Ce n'est pas une clause de défiance. C'est une assurance, et elle conditionne la qualité de toute la relation.

Pourquoi le sujet revient sur la table

Dans la finance, ce n'est plus une option. Le règlement européen DORA, applicable depuis janvier 2025, impose aux entités financières une stratégie de sortie documentée pour les prestataires informatiques qui supportent des fonctions critiques ou importantes (article 28). Scénarios de sortie, délais de transition, transfert des données, ressources nécessaires, tests : tout doit être écrit et pouvoir être exécuté sans interruption d'activité.

Vous n'êtes pas une banque ? La logique vaut quand même. Une équipe nearshore qui porte votre produit, votre support client ou votre back-office est une fonction critique. Si elle s'arrête du jour au lendemain, votre activité s'arrête aussi.

Les trois raisons qui déclenchent une sortie

Une sortie n'est pas forcément un échec. Dans les faits, elle arrive pour trois raisons.

  • La réussite. L'équipe fonctionne si bien que vous voulez l'internaliser dans votre propre filiale. C'est le principe même du build-operate-transfer.
  • La dérive. Qualité en baisse, turnover non maîtrisé, facturation qui gonfle. Vous voulez changer de prestataire.
  • Le changement de stratégie. Rachat, recentrage, nouveau pays. Le périmètre externalisé n'a plus de sens tel quel.

Dans les trois cas, la question est la même : qu'est-ce qui vous appartient vraiment, et combien de temps faut-il pour le récupérer ?

Ce qu'il faut verrouiller dans le contrat

La propriété de ce qui est produit

Le code, les documents, les process, les bases de connaissances : tout ce que l'équipe produit pour vous doit vous appartenir, explicitement, au fil de l'eau. Pas à la fin du contrat. Pas « sur demande ». Les dépôts de code et les outils de travail doivent être hébergés sur vos comptes, pas sur ceux du prestataire.

Les données

Où sont-elles, qui y accède, sous quel format vous les récupérez, et dans quel délai. Le prestataire doit aussi s'engager à les supprimer une fois la restitution faite, avec une attestation. C'est d'ailleurs une exigence du RGPD pour tout sous-traitant qui traite des données personnelles.

Le plan de transition

Le contrat doit prévoir une période de transition chiffrée : durée, niveau de service maintenu pendant cette période, transfert de connaissances, tarif applicable. Un prestataire qui refuse d'écrire ces chiffres vous dit quelque chose.

Le sort de l'équipe

C'est le point que la plupart des contrats oublient, et c'est souvent le plus important. Pouvez-vous proposer un poste aux personnes qui travaillent sur votre projet ? Sous quelles conditions ? Une clause de non-sollicitation absolue signifie qu'en partant, vous perdez les gens qui connaissent votre métier. Négociez une option de reprise, avec des frais connus à l'avance.

La réversibilité se construit au quotidien

Un contrat bien écrit ne suffit pas. Si rien n'est documenté pendant trois ans, aucune clause ne fera apparaître la connaissance le jour du départ.

  • Documenter en continu. Chaque process, chaque décision d'architecture, chaque procédure de support est écrit au moment où il est créé, dans vos outils.
  • Garder un pied dedans. Au moins une personne de votre côté comprend réellement ce que fait l'équipe, techniquement et fonctionnellement. Sans ce binôme interne, vous ne pilotez pas, vous subissez.
  • Éviter les boîtes noires. Méfiez-vous des outils propriétaires du prestataire qui deviennent indispensables. Ce que vous ne pouvez pas faire tourner sans lui vous enferme.
  • Tester. Une fois par an, posez la question : si le contrat s'arrêtait dans trois mois, que faudrait-il faire ? Si personne ne sait répondre, vous avez un chantier.

Le paradoxe : une bonne réversibilité fidélise

On pourrait croire qu'un client qui peut partir facilement partira. C'est l'inverse. Un prestataire qui sait que vous pouvez reprendre la main à tout moment n'a qu'un seul moyen de vous garder : être bon. La réversibilité remplace la dépendance par la performance.

C'est aussi un test de sérieux au moment du choix. Posez la question dès le premier rendez-vous. Un partenaire solide vous répond avec un plan. Un partenaire fragile change de sujet.

Le modèle qui intègre la sortie dès le départ

Le build-operate-transfer pousse cette logique jusqu'au bout. La sortie n'est plus un risque, c'est l'objectif. Le partenaire recrute et opère l'équipe pendant la phase de démarrage, puis la transfère dans votre propre structure une fois qu'elle est stable. Tout est conçu pour ce moment : les contrats de travail, les outils, la documentation, la culture.

C'est la logique que nous avons appliquée pour Ippon Technologies : une filiale IT opérationnelle au Maroc en moins de six mois, avec une équipe qui appartient au groupe, pas à un intermédiaire.

En résumé

Avant de signer, posez quatre questions : à qui appartient ce qui est produit, comment je récupère mes données, combien de temps dure la transition, et que deviennent les personnes. Si les réponses sont claires et écrites, vous pouvez vous engager sereinement.

Vous préparez une équipe nearshore et voulez regarder la question de la sortie avant celle de l'entrée ? Écrivez-nous, c'est souvent par là que nous commençons.