Build-Operate-Transfer au Maroc : le modèle qui redonne aux DSI européens le contrôle qu'ils ont cédé aux hyperscalers

# Build-Operate-Transfer au Maroc : le modèle qui redonne aux DSI européens le contrôle qu'ils ont cédé aux hyperscalers

En 2026, la question n'est plus de savoir si les PME et ETI européennes ont besoin de capacités IT offshore. Elle est de savoir à qui elles confient la clé de leur infrastructure — et si elles pourront un jour la récupérer.

Le modèle Build-Operate-Transfer (BOT) appliqué au nearshore marocain revient dans les conversations des DSI avec une insistance nouvelle. Pas par nostalgie d'une époque révolue, ni par idéologie anti-cloud. Mais parce que les contrats signés à la va-vite avec les acteurs américains dominants en 2021-2023 arrivent à renouvellement — et que les équipes financières regardent les factures avec une expression que je qualifierai poliment d'inquiète.

Il faut nommer ce qui se passe : le modèle d'externalisation IT vers les grands acteurs US repose structurellement sur une asymétrie de pouvoir que beaucoup d'organisations européennes n'avaient pas anticipée. Le BOT marocain, lui, propose une trajectoire différente. Pas magique. Pas sans friction. Mais structurellement plus compatible avec une logique de réappropriation du SI.

Comparons trois approches sur les critères qui comptent vraiment pour un budget IT et une gouvernance durable.

Les trois modèles en présence

Modèle A — Externalisation managée vers un acteur américain dominant

Sous-traitance complète d'une fonction IT (support, développement, ops) à un intégrateur ou éditeur US opérant depuis ses propres centres offshore (Inde, Philippines, parfois Pologne sous enseigne américaine).

Modèle B — Centre de services nearshore classique (Maroc, Roumanie, Portugal)

Equipe dédiée hébergée chez un prestataire local, pilotée depuis l'Europe, sans clause de transfert de propriété. Le modèle dominant depuis les années 2000 dans le nearshore francophone.

Modèle C — Build-Operate-Transfer (BOT) au Maroc

Le prestataire construit la structure opérationnelle (recrutement, management, process, tooling), l'opère pendant une période définie, puis transfère la structure — équipes, contrats, savoir-faire — à l'entreprise cliente. L'objectif explicite est que le client devienne autonome.

Critère 1 : Architecture de la dépendance

C'est le critère que les DSI regardent en dernier, et c'est une erreur stratégique.

Avec le modèle A, la dépendance est architecturale dès le départ. Les outils de monitoring, les pipelines CI/CD, les référentiels de tickets, les accès aux environnements de production — tout est hébergé et administré dans l'écosystème du prestataire américain. Quand le contrat se termine ou que les tarifs augmentent, migrer coûte autant — parfois plus — que rester. Ce n'est pas un accident de conception. C'est le modèle économique.

Avec le modèle B classique, la dépendance est plus douce mais réelle. L'équipe offshore développe une connaissance métier et technique que l'organisation cliente ne capitalise pas toujours en interne. Si le prestataire est racheté — ce qui arrive — ou change de stratégie, le client repart de zéro avec une équipe qu'il n'a jamais réellement managée.

Le modèle BOT est le seul des trois à poser la question de la dépendance comme un problème à résoudre, pas à gérer. La phase « Operate » est explicitement conçue pour que les équipes internes du client montent en compétence. La phase « Transfer » n'est pas une clause contractuelle théorique — c'est l'objectif commercial du prestataire, ce qui aligne les incitations d'une façon que je trouve rare dans ce secteur.

Verdict : le BOT est le seul modèle structurellement orienté vers la désintoxication de la dépendance.

Critère 2 : Gouvernance des données et conformité RGPD

En 2026, après les turbulences réglementaires autour du Cloud Act américain et les mises en demeure successives des autorités de protection des données européennes, ce critère n'est plus théorique pour un RSSI sérieux.

Le modèle A pose un problème structurel que les DPA (Data Processing Agreements) ne résolvent pas vraiment : les données traitées par les équipes offshore d'un prestataire américain restent potentiellement accessibles à des juridictions non-européennes. Les clauses contractuelles types (SCCs) offrent une protection juridique, pas une protection technique.

Le modèle B nearshore classique, lorsqu'il opère depuis le Maroc ou la Roumanie avec un prestataire européen, est nettement plus propre sur ce point — à condition que la chaîne de sous-traitance soit auditée. Le Maroc dispose depuis 2009 d'une législation sur la protection des données personnelles (loi 09-08) et d'une autorité dédiée, la CNDP. C'est imparfait, mais c'est une base.

Le modèle BOT, dans sa phase de transfert, offre quelque chose que les deux autres n'offrent pas : la capacité pour le client d'internaliser réellement le traitement des données sensibles. Une fois le transfer effectué, l'équipe marocaine est une équipe interne à l'entreprise européenne — avec les contrats, les accès et la gouvernance qui vont avec. La surface d'exposition aux juridictions étrangères se réduit mécaniquement.

Un acteur comme Intelcia, groupe marocain coté opérant dans plusieurs pays européens, a construit une partie de son positionnement sur cette proposition de valeur réglementaire. Ce n'est pas neutre.

Verdict : BOT et nearshore classique européen sont supérieurs au modèle US sur la gouvernance des données. Le BOT a l'avantage de la trajectoire.

Critère 3 : Impact budgétaire et exposition au risque tarifaire

Je vais être direct : la raison pour laquelle ce sujet revient en force en 2026, c'est que les hyperscalers et grands intégrateurs américains ont procédé à des révisions tarifaires significatives à chaque renouvellement de contrat depuis 2023. Ce n'est pas une surprise — c'est la conséquence logique d'une position dominante consolidée.

Le modèle A expose l'organisation à ce risque de façon maximale. Non seulement les tarifs des licences logicielles et des services cloud augmentent, mais les coûts de sortie (migration, requalification des équipes, refonte des intégrations) créent ce qu'on appelle pudiquement un « coût de switching » — et moins pudiquement, une prison dorée.

Le modèle B offre plus de flexibilité tarifaire à court terme — changer de prestataire nearshore est plus simple que migrer d'un écosystème US. Mais sans clause de transfert, le capital humain et organisationnel reste chez le prestataire. Le budget de transition reste élevé.

Le modèle BOT présente une structure de coût différente : les investissements de setup sont plus lourds en phase Build, mais la phase Transfer amortit ces coûts sur la durée. Une fois l'équipe internalisée, le DSI maîtrise sa masse salariale, ses outils et ses processus. L'exposition au risque tarifaire externe s'effondre. C'est une logique de capex vs opex qui mérite d'être modélisée sérieusement avec la DAF — pas traitée comme une simple ligne de sous-traitance.

Verdict : le BOT impose un effort budgétaire initial plus structuré, mais c'est le seul modèle qui réduit durablement l'exposition au pouvoir de marché des prestataires dominants.

Critère 4 : Intégration technique et continuité opérationnelle

Le BOT n'est pas sans contraintes techniques. La phase Build exige une documentation rigoureuse des processus, une architecture IT préalablement stabilisée côté client, et une volonté managériale réelle de piloter la transition. Les DSI qui choisissent le BOT par commodité, sans ressources internes pour absorber le transfer, échouent — et je pense qu'il faut le dire clairement.

Le modèle B nearshore classique reste supérieur en matière de rapidité de mise en œuvre. Pour une ETI qui a besoin de capacités IT opérationnelles en moins de six mois, c'est souvent le bon choix à court terme.

Le modèle A offre une intégration technique immédiate — au prix d'une dépendance aux standards propriétaires de l'acteur américain. Les connecteurs, les API, les formats de données sont optimisés pour l'écosystème du prestataire. Migrer vers un autre environnement implique souvent de réécrire ce qu'on croyait avoir construit.

Tableau comparatif

| Critère | Modèle A (US dominant) | Modèle B (Nearshore classique) | Modèle C (BOT Maroc) |

|---|---|---|---|

| Architecture de dépendance | Forte, structurelle | Modérée, humaine | Faible à terme |

| Gouvernance RGPD | Risquée (juridiction US) | Acceptable si chaîne auditée | Maîtrisable post-transfer |

| Exposition risque tarifaire | Maximale | Modérée | Faible post-transfer |

| Délai de mise en œuvre | Court | Court à moyen | Moyen à long |

| Capital organisationnel | Reste chez le prestataire | Reste chez le prestataire | Transféré au client |

| Alignement souveraineté EU | Incompatible | Partiel | Fort |

Ce que j'en pense

Le BOT marocain n'est pas la réponse à tout. Ce n'est pas un produit qu'on achète — c'est un engagement organisationnel qui suppose que le DSI ait la volonté politique interne, le soutien de la direction générale, et une vision à trois ou quatre ans de ce que doit être son SI.

Mais il faut nommer ce que les deux autres modèles font : ils perpétuent une logique où les PME et ETI européennes financent le développement des capacités des acteurs dominants, américains pour la plupart, sans jamais capitaliser en propre sur ce qu'elles construisent.

En 2026, alors que la question de la souveraineté numérique est passée du débat académique à la réalité des budgets IT sous pression, il me semble urgent que les DSI européens cessent de traiter l'externalisation comme une décision neutre. Elle ne l'a jamais été.

Le BOT, avec ses contraintes réelles, est au moins honnête sur ce qu'il propose : non pas un service, mais une trajectoire de réappropriation. C'est exactement la conversation que nous devons avoir.