Un cas de figure banal, reconstitué à partir de situations que beaucoup de dirigeants marocains reconnaîtront : une PME de Casablanca fait développer son site e-commerce par une petite agence. Trois ans plus tard, les correctifs traînent, la facture de maintenance monte, et le gérant décide d’aller voir ailleurs. Il demande le code source, les accès à l’hébergement et le transfert du nom de domaine. Réponse : le code reste la propriété de l’agence, le serveur est mutualisé avec six autres clients, et le domaine a été acheté avec la carte bancaire du fondateur de l’agence.
Ce n’est pas forcément de la mauvaise foi. C’est ce que prévoit le contrat signé trois ans plus tôt, ou plutôt ce qu’il ne prévoit pas : aucune clause de cession des droits, aucun plan de restitution, aucun inventaire des accès. Le prestataire applique la lettre d’un document que personne n’a relu depuis.
D’où une règle qui surprend souvent : la sortie se prépare avant de signer ailleurs, pas après. Les trois erreurs ci-dessous sont celles qui coûtent le plus cher au moment de la bascule, et chacune se corrige en quelques jours de travail administratif.
Pourquoi changer de prestataire IT est plus risqué qu’il n’y paraît
Le code source n’est presque jamais le vrai point de blocage. Ce sont les comptes. Un projet web ou mobile en production repose sur une quinzaine de dépendances administratives, et chacune appartient nominativement à quelqu’un :
- le nom de domaine chez le registrar, avec son contact titulaire et son code de transfert
- la zone DNS, souvent hébergée ailleurs que le site lui-même
- le compte d’hébergement ou la console cloud, et surtout le compte racine qui porte la facturation
- la messagerie professionnelle et les enregistrements MX
- le dépôt Git, le pipeline de déploiement et les variables d’environnement
- le compte marchand CMI et les clés de la passerelle de paiement
- Search Console, Analytics, Tag Manager, Google Business Profile
- les comptes développeur App Store et Google Play, s’il existe une application
- les licences de thème, les plugins payants, les API tierces et le service SMS
Perdre le code coûte des semaines de développement. Perdre le domaine ou le compte marchand coûte du chiffre d’affaires le jour même, et c’est la raison pour laquelle un changement de prestataire se pilote comme une migration : un inventaire, un ordre d’opérations, des dates. Pas comme la fin d’une relation commerciale qu’on règle par téléphone.
Erreur n°1 : un contrat sans clause de réversibilité
La clause de réversibilité est le paragraphe qui décrit ce qui se passe à la fin, quelle que soit la raison de cette fin. Elle est absente de la plupart des devis de développement de deux pages signés au Maroc, parce que personne n’a envie de parler séparation le jour où le projet démarre.
Une clause utile tient en une demi-page et répond à six questions : quoi (code, données, documentation, accès, configurations), sous quel format, dans quel délai après la demande, avec combien d’heures d’assistance incluses pour accompagner le transfert, à quel tarif au-delà, et à qui appartiennent les droits d’exploitation du code développé spécifiquement pour vous. Sur ce dernier point, la cession de droits d’auteur sur un logiciel se prouve par écrit : si votre contrat est muet, ne supposez pas que le code vous appartient, et faites relire la rédaction de la clause par un juriste avant de la négocier.
Deux détails changent beaucoup de choses en pratique. D’abord, rattachez une part du solde final à la recette de la restitution, et non à la mise en production. Ensuite, demandez que l’inventaire des accès et la documentation soient mis à jour une fois par an pendant la vie du contrat, au lieu d’être produits le dernier jour du préavis. Un prestataire sérieux accepte sans discuter, ne serait-ce que parce que cela lui évite de reconstituer l’historique en urgence quand le développeur d’origine a quitté sa boîte depuis deux ans.
Si vous êtes justement en train de préparer le contrat suivant, la réversibilité contrat informatique se traite dans le même document que les engagements de service : le cahier des charges est le bon endroit pour la décrire, et le devis celui où vous vérifiez qu’elle n’a pas disparu en route.
Erreur n°2 : le prestataire seul détenteur des accès hébergement et domaine
Une vérification de dix minutes, à faire aujourd’hui. Interrogez le whois de votre domaine et lisez le nom du titulaire. Ouvrez la console de votre hébergeur et regardez quelle adresse reçoit les factures. Ouvrez Search Console et regardez qui figure comme propriétaire. Si trois réponses sur quatre renvoient vers votre prestataire, vous ne consommez pas un service, vous dépendez d’une personne.
La correction n’exige aucun conflit. Les comptes structurants sont créés par l’entreprise, avec une adresse neutre du type [email protected] relevée par deux personnes en interne, et une carte bancaire de la société pour la facturation. Le prestataire est ensuite invité comme administrateur délégué. Son travail quotidien ne change pas d’un pouce, il ne peut simplement plus repartir avec la clé.
Dans l’ordre des priorités : registrar, DNS, compte cloud racine, Google Workspace ou Microsoft 365, comptes développeur mobiles, compte marchand CMI, outil de sauvegarde. Les comptes App Store et Play Console méritent une insistance particulière : s’ils sont au nom de l’agence, votre fiche, vos avis et votre historique de téléchargements lui appartiennent, et un transfert refusé signifie republier à zéro, avec une nouvelle URL et un compteur d’installations remis à un.
Erreur n°3 : du code et des données livrés sans format exploitable
Une reprise de code source réussie ne ressemble pas à une archive zip envoyée par WeTransfer la veille de la fin du préavis. Elle ressemble à un dépôt Git avec son historique, un fichier d’installation qui permet à un développeur extérieur de faire tourner le projet en local le premier jour, la liste des variables d’environnement (les valeurs passant par un canal séparé), les scripts de migration de base, les versions exactes des dépendances, et la liste de ce qui est sur-mesure par opposition à ce qui vient d’un thème ou d’un composant acheté sous licence.
Côté données, exigez des exports dans des formats standards, dump SQL ou CSV, pas des PDF ni des captures d’écran. Puis faites le test qui compte : restaurez vous-même la sauvegarde sur un serveur neutre avant de solder la facture. C’est là qu’on découvre que l’export contient la table des commandes mais pas les pièces jointes, ou que la base de test et la base de production n’ont pas le même schéma depuis dix-huit mois.
Un prestataire qui ne peut livrer qu’un zip vous renseigne aussi sur la façon dont le projet a été construit. Cela ne se résout pas par la négociation, mais ça se budgète.
Ce que coûte une reprise mal préparée
Les postes de dépense sont toujours les mêmes, seule l’ampleur varie. Un audit de reprise sérieux, code plus infrastructure, se situe souvent entre 8 000 et 20 000 MAD pour un site vitrine ou une petite application, et plutôt entre 25 000 et 60 000 MAD pour une application métier ou un e-commerce avec intégrations (paiement, ERP, logistique). S’y ajoutent la reconstitution des environnements non documentés, le redéveloppement des modules illisibles, et le recouvrement des deux contrats pendant un ou deux mois de fonctionnement en parallèle.
Sur les délais, l’écart est frappant. Avec un inventaire à jour, une documentation correcte et un interlocuteur coopératif, le nouveau prestataire devient autonome en deux à trois semaines. Sans rien de tout cela, comptez plutôt six à douze semaines avant de pouvoir livrer la première évolution, pendant lesquelles le produit est gelé. Et un repreneur qui chiffre une maintenance au forfait sans phase d’audit préalable ne vous fait pas une faveur, il devine.
La checklist de transition à exiger avant de signer ailleurs
Avant d’annoncer votre départ, récupérez ce à quoi vous avez déjà accès légitimement : exports, sauvegardes, documentation, factures, identifiants que vous détenez. Ce n’est pas une ruse, c’est l’inventaire qu’on fait avant un déménagement. Ensuite, déroulez dans cet ordre :
- inventaire écrit de tous les comptes, avec le nom du titulaire et l’adresse e-mail de récupération de chacun
- sauvegarde complète copiée chez vous, puis restaurée et testée sur un environnement neutre
- exports de données dans des formats lisibles par un tiers, relations et pièces jointes incluses
- dépôt de code avec historique, documentation d’installation et liste des licences tierces
- plan de bascule daté, avec fenêtre de coupure acceptée et TTL DNS abaissé 48 heures avant
- période de fonctionnement en parallèle couvrant au moins un cycle métier complet (une clôture, une paie, un mois de ventes)
- un interlocuteur nommé chez le prestataire sortant et un volume d’heures d’assistance chiffré
- solde final conditionné à la recette de la restitution, pas à la date de fin de contrat
- préavis notifié par écrit dans les formes prévues, pour ne pas offrir un motif de blocage
- clause de réversibilité négociée dans le nouveau contrat, avant signature et non en avenant
Le choix du repreneur est un sujet distinct, et les critères utiles (références vérifiables, équipe réellement affectée, engagements de service) sont détaillés dans notre guide pour choisir un ESN au Maroc. Un conseil tout de même : dites au candidat que vous arrivez d’une reprise difficile. Sa réaction, audit d’abord ou devis immédiat, vous apprendra beaucoup.
CNDP et continuité : ce qui doit suivre le client, jamais le prestataire
Sur les données personnelles, la loi 09-08 distingue le responsable du traitement et le sous-traitant. Dans une relation PME/agence classique, le responsable est votre société : la déclaration CNDP doit donc être à votre nom. Sortez le récépissé et regardez. Si la formalité a été déposée par l’agence pour son propre compte, vous avez une régularisation à faire, et les modalités exactes sont à vérifier sur le site de la CNDP plutôt que sur parole.
Le contrat de sous-traitance doit par ailleurs prévoir la restitution puis la suppression des données à la fin de la relation, l’interdiction de les utiliser à d’autres fins, et le lieu d’hébergement. Les copies oubliées sont presque toujours les mêmes : fichier clients dans la boîte mail du chef de projet, exports Excel sur son poste, base de préproduction non anonymisée. Demandez une attestation de suppression datée, et profitez du changement pour reprendre la checklist de conformité CNDP au nom de la société.
Le bon ordre des opérations
Inventaire, récupération de ce qui est accessible, audit technique de ce que vous détenez réellement, négociation de la restitution et du préavis, choix du repreneur avec clause de réversibilité, bascule datée avec fonctionnement en parallèle. Dans cet ordre, l’opération prend quelques semaines de plus au départ et vous épargne les trois mois de reconstitution qui arrivent sinon.
C’est précisément le type de mission de conseil que nous menons chez Arrowlancer : auditer le code et l’infrastructure que vous récupérez, rédiger la clause de réversibilité et le plan de transition, piloter la bascule sans interruption de service. Vous trouverez nos domaines d’intervention ici, et si vous êtes déjà en préavis, décrivez-nous la situation avant de signer le contrat suivant.