Changer de prestataire informatique sans rien perdre : réversibilité, accès et code source

Changer de prestataire informatique est rarement une décision légère. Le projet n'avance plus, les délais glissent, les factures s'accumulent, ou tout simplement le prestataire ne répond plus. Dans ces moments, le vrai risque n'est pas technique. Le vrai risque, c'est de découvrir trop tard que le nom de domaine, l'hébergement, le code source ou le compte développeur de votre application sont au nom de quelqu'un d'autre.

Ce guide détaille la méthode que nous appliquons quand nous reprenons un projet : ce qu'il faut vérifier dans le contrat, la liste complète des accès à récupérer, l'ordre dans lequel agir, et les pièges qui font perdre des semaines.

01Ce que dit votre contrat : la clause de réversibilité

La réversibilité désigne la capacité à récupérer vos données, votre code et vos accès à la fin d'un contrat, pour les confier à un autre prestataire ou les reprendre en interne. Dans un contrat informatique ou un contrat SaaS, la clause de réversibilité précise ce que le prestataire doit vous remettre, sous quel format, dans quel délai et à quel coût.

Avant d'annoncer quoi que ce soit, relisez votre contrat et notez :

• s'il existe une clause de réversibilité, et ce qu'elle couvre (données, code, documentation, accompagnement) ;
• la durée du préavis et les conditions de résiliation ;
• la clause de propriété intellectuelle : qui détient les droits sur le code développé ;
• les éventuels frais de restitution prévus.

À qui appartient le code source ?

C'est la question la plus importante, et la réponse surprend souvent. En France, un logiciel développé par un prestataire extérieur n'appartient pas automatiquement au client qui l'a payé : les droits d'auteur restent au prestataire tant qu'une cession n'a pas été prévue par écrit. Si votre contrat contient une clause de cession des droits, vous êtes propriétaire du code. Sinon, il faut la négocier. Pour un cas précis, faites relire votre contrat par un avocat : ce guide donne des repères, pas un avis juridique.

02La liste complète des accès à récupérer

Voici les éléments que nous vérifions systématiquement, du plus critique au plus secondaire. Pour chacun, la règle est la même : vous devez en être propriétaire, pas simple invité.

Le nom de domaine et les DNS

Le nom de domaine est l'actif le plus précieux : sans lui, votre site et vos adresses email disparaissent. Vérifiez chez quel registraire il est enregistré (OVHcloud, Gandi, IONOS, o2switch…) et surtout le nom du titulaire. Le titulaire doit être votre société, avec une adresse email que vous contrôlez.

Pour un transfert de nom de domaine vers un autre registraire, il vous faut le code d'autorisation (souvent appelé code de transfert ou code EPP), et le domaine doit être déverrouillé. Beaucoup d'extensions imposent un délai après un enregistrement ou un transfert récent avant de pouvoir le transférer à nouveau : renseignez-vous auprès du registraire. Les DNS peuvent être gérés ailleurs que chez le registraire, par exemple chez Cloudflare : récupérez aussi cet accès.

L'hébergement et les serveurs

Demandez un accès administrateur, pas seulement un accès FTP. Si le serveur est loué au nom du prestataire, prévoyez une migration vers un hébergement à votre nom : c'est l'occasion de remettre à plat les coûts et la sécurité.

Le code source

Le code doit être dans un dépôt (GitHub, GitLab, Bitbucket) dont vous êtes propriétaire, avec tout l'historique des modifications. Une archive zip envoyée par email ne suffit pas : vous perdez l'historique, et rien ne garantit qu'elle est complète ni qu'elle correspond à ce qui tourne en production. Pour récupérer le code source d'un site web ou d'une application, la bonne méthode est simple : transférer le dépôt à votre organisation, ou vous y donner les droits d'administrateur.

Les comptes App Store et Google Play

Pour une application mobile, le compte Apple Developer et la Google Play Console doivent être à votre nom. Apple et Google proposent chacun une procédure officielle pour transférer une application d'un compte à un autre. Ces transferts imposent des conditions (comptes en règle, contrats acceptés, certains services à reconfigurer) et prennent du temps : lancez-les tôt.

03Dans quel ordre agir

1. Sécuriser le nom de domaine et les DNS. C'est ce qui peut couper le site et les emails du jour au lendemain.
2. Récupérer le code et une sauvegarde de la base. Vérifiez que la sauvegarde s'ouvre réellement.
3. Basculer les comptes de paiement et des stores à votre nom.
4. Changer tous les mots de passe et révoquer les anciennes clés d'API. L'ancien prestataire ne doit plus avoir d'accès.
5. Faire auditer le projet par la nouvelle équipe avant de lancer de nouveaux développements.

04Les erreurs qui coûtent cher

• Annoncer la fin du contrat avant d'avoir sécurisé les accès critiques.
• Accepter une archive zip à la place du dépôt Git.
• Ne pas tester la sauvegarde de la base de données.
• Oublier les comptes secondaires : emailing, Search Console, clés d'API.
• Repartir de zéro par réflexe, sans audit, alors qu'une partie du travail est réutilisable.

05Comment annoncer la fin du contrat

Une fois les accès critiques sécurisés, la fin du contrat se gère par écrit. Envoyez une notification formelle, en respectant le préavis prévu, et joignez la liste précise de ce que vous attendez : dépôt de code, sauvegardes, accès, documentation, et la date à laquelle vous les attendez. Restez factuel et courtois : vous aurez probablement besoin de quelques réponses techniques de l'ancien prestataire pendant la transition.

Demandez aussi un inventaire écrit des services utilisés par le projet. C'est souvent là que se cachent les surprises : un service d'envoi d'emails ouvert sur une carte bancaire personnelle, une clé d'API rattachée à un compte de test, un certificat qui expire dans trois semaines.

06Le cas d'un logiciel SaaS : récupérer vos données

Si vous utilisez un logiciel en SaaS plutôt qu'un développement sur mesure, la question n'est plus le code mais les données. Vérifiez dans le contrat sous quel format elles peuvent être exportées (CSV, SQL, API), si l'export est complet (pièces jointes, historiques, paramètres) et combien de temps elles restent disponibles après la résiliation. Pour les données personnelles de vos clients, le RGPD impose par ailleurs des obligations à chaque partie : prévoyez leur transfert et leur suppression chez l'ancien prestataire.

07Que faire si le prestataire ne répond plus ?

C'est la situation la plus stressante, et elle n'est pas rare. Quelques repères :

• Nom de domaine : si vous êtes le titulaire enregistré, le registraire dispose de procédures pour vous rendre l'accès, sur justificatifs. Si le titulaire est le prestataire, la situation est plus complexe et justifie un conseil juridique.
• Hébergement : si le compte est à votre nom ou payé par votre société, l'hébergeur peut vous redonner la main, là encore sur justificatifs.
• Comptes stores : le support d'Apple et de Google peut vous accompagner si le compte appartient à votre entreprise.
• Code source : sans accès au dépôt, une partie du code peut parfois être reconstituée depuis le serveur de production. C'est un dernier recours, et l'audit dira ce qui est récupérable.

Dans tous les cas, gardez une trace écrite de vos relances : elle vous sera utile si la situation doit être réglée par d'autres moyens.

08Pour la suite : prévoir la réversibilité dès le départ

La meilleure façon de changer de prestataire sans douleur, c'est de l'avoir prévu dès le premier contrat. Avec votre prochain prestataire, exigez une clause de cession des droits sur le code, une clause de réversibilité claire, des comptes ouverts à votre nom dès le premier jour, et une documentation tenue à jour. Un bon prestataire n'a aucune raison de refuser : il ne vous retient pas par vos accès, mais par la qualité de son travail.

09Après le changement : l'audit de reprise

Une fois les accès en main, le nouveau prestataire doit comprendre ce qui existe avant de toucher à quoi que ce soit : qualité du code, sécurité, dépendances, hébergement, coûts. C'est exactement le rôle de l'audit Lunarion : un diagnostic écrit, des priorités et le coût de chaque option, avant tout engagement.

10Questions fréquentes