1. Un phénomène plus courant qu’on ne l’imagine
Dans de nombreuses entreprises marocaines et francophones, des projets web ou applicatifs ont été confiés, parfois depuis plusieurs années, à un prestataire externe unique : agence digitale, freelance, éditeur local ou intégrateur.
La logique est simple : déléguer la complexité technique à un partenaire de confiance, et se concentrer sur les usages métier.
Mais dans certains cas, cette relation glisse vers un verrouillage technologique, parfois involontaire, parfois entretenu :
le code source n’est pas livré ou mal documenté,
les accès serveurs sont partiels, ou détenus uniquement par le prestataire,
aucune procédure de transfert ou de montée en compétence interne n’est prévue.
Résultat : l’entreprise devient dépendante d’un seul acteur, sans marges de manœuvre, même pour de simples évolutions.
2. Deux cas typiques observés sur le terrain
A. Plateforme web métier verrouillée techniquement
Une entreprise du secteur immobilier a fait développer une plateforme de gestion de projets.
Au fil des ans :
le prestataire ajoute des modules,
Mais aucun autre prestataire ne peut intervenir :
le code n’a jamais été livré intégralement,
les accès sont limités à une interface FTP,
aucune documentation fonctionnelle ou technique n’existe.
Lorsqu’un changement s’impose (nouveau design, connexion à un CRM), l’entreprise découvre qu’elle ne maîtrise pas son propre outil.
B. Hébergement serveur contrôlé à 100 % par l’intégrateur
Une PME industrielle a confié à une société IT la gestion complète de ses serveurs applicatifs.
Lorsqu’un audit sécurité externe demande :
la mise en place de logs,
une révision des accès SSH,
une séparation entre PROD et pré-prod,
le prestataire refuse, invoquant des “risques” ou des “limitations de l’infrastructure”. En réalité, l’infogérance a été configurée pour empêcher toute intervention sans lui.
L’entreprise est bloquée, même pour des sujets critiques.
3. Pourquoi ces situations se produisent
A. Une confiance excessive… jusqu’à ce qu’elle se retourne
La relation de départ est souvent bonne. On s’appuie sur un prestataire disponible, réactif, parfois très proche.
Mais faute de cadrage contractuel ou de gouvernance claire, cette proximité devient, au fil du temps, une forme de dépendance structurelle.
B. Des contrats flous ou incomplets
Beaucoup de contrats d’édition ou de prestation ne précisent pas :
la propriété du code source,
les modalités de réversibilité,
l’accès aux environnements techniques.
Ce flou laisse place à l’interprétation… ou à la rétention.
C. Un manque d’anticipation côté client
Souvent, les entreprises ne pensent pas à la phase “post-projet” :
Comment changer de prestataire si besoin ?
Qui peut maintenir l’outil en interne ?
Que faire en cas de conflit ou de fin de contrat ?
L’absence de ces réflexes ouvre la porte au verrouillage.
4. Les risques concrets pour l’entreprise
Un prestataire verrouillé peut, de fait :
bloquer la migration vers une nouvelle architecture,
refuser certaines évolutions sans surcoût,
ralentir le déploiement de nouveaux outils interfacés,
voire suspendre l’accès ou la maintenance en cas de litige.
Au-delà du désagrément, cela devient un risque stratégique pour l’entreprise :
incapacité à réagir à un incident,
perte de souveraineté sur des actifs numériques essentiels.
voire suspendre l’accès ou la maintenance en cas de litige.
5. Comment anticiper ou désamorcer un verrouillage technologique
A. Clarifier la propriété du code, des accès et des livrables
Tout contrat de développement ou d’infogérance doit préciser :
qui est propriétaire du code (par défaut, c’est souvent le prestataire),
la remise des sources au fil du projet, pas uniquement en fin,
les droits d’accès aux serveurs (admin, supervision, logs…),
les modalités de réversibilité ou de passation.
B. Exiger une documentation technique et fonctionnelle progressive
Chaque livrable clé doit être accompagné :
d’un guide d’installation,
d’un schéma d’architecture,
d’un fichier de configuration documenté.
Cela permet de reprendre la main sans tout reconstruire en cas de rupture.
C. Mettre en place une gouvernance multi-acteurs
Impliquer plusieurs partenaires ou référents internes dans le suivi :
audit ponctuel du code par une tierce partie,
double hébergement ou supervision externe,
accès partagé à la plateforme de gestion de version (GitLab, Bitbucket…).
D. Construire un plan de réversibilité, même en période de paix
Ce plan doit décrire :
les étapes de transfert de compétences,
la restitution des accès et données,
les conditions de maintenance intermédiaire
C’est une assurance silencieuse, qui évite de devoir tout improviser dans l’urgence.
6. Autonomie et continuité comme lignes directrices
Un bon prestataire ne verrouille pas son client. Il sait construire une relation durable sans créer de dépendance exclusive.
Du côté client, il est essentiel de poser dès le départ les conditions d’une autonomie progressive, même si l’externalisation reste forte.
Chez RFC Digital, nous avons accompagné plusieurs entreprises dans des reprises techniques sensibles, où la documentation était absente, les accès partiels, et la dépendance totale.
Notre rôle n’est pas de remplacer un prestataire, mais de reconstruire un socle ouvert, documenté, évolutif, sur lequel l’entreprise peut s’appuyer durablement — quelle que soit la suite.
Vous avez un doute sur votre niveau de contrôle réel sur vos plateformes ou serveurs ?
Un simple audit de continuité technique peut lever les zones d’ombre… avant qu’elles ne deviennent des blocages.
