L’open source peut-il accélérer la souveraineté numérique du Maroc ?

À 8 h 15, dans une PME marocaine qui accompagne des entreprises exportatrices, une responsable reçoit un message client, ouvre un contrat, vérifie une facture et demande à un assistant d’IA de retrouver la clause qui l’intéresse. En quelques secondes, l’outil propose une réponse. Le travail paraît simple. Pourtant, plusieurs questions sont déjà engagées : le document a-t-il quitté l’entreprise ? Le modèle a-t-il utilisé la bonne version du contrat ? Qui pourra expliquer la réponse si elle est contestée ?

Au départ, la solution semble idéale. La PME choisit un outil de gestion, branche une API d’intelligence artificielle et dépose ses documents dans un espace Cloud. Elle paie selon le nombre de requêtes et bénéficie d’une mise en service rapide. Puis les habitudes s’installent : les données prennent un format propriétaire, les équipes apprennent une interface qu’elles ne contrôlent pas et chaque nouvelle fonction rapproche un peu plus l’entreprise de son fournisseur.

Le jour où le tarif augmente, où le modèle change ou où une fonctionnalité disparaît, la décision n’est plus seulement technique. Elle touche le budget, les contrats, les clients et parfois la confidentialité des données. Cette situation porte un nom : le vendor lock-in, c’est-à-dire la dépendance à un fournisseur dont il devient coûteux ou risqué de sortir.

La question n’est pas de refuser les technologies internationales. Elle est plus exigeante : que pouvons-nous comprendre, modifier, héberger, auditer et remplacer ? L’open source peut accélérer la souveraineté numérique du Maroc, mais il ne la garantit pas. L’ouverture du code ou des modèles n’a de valeur que si elle s’accompagne de compétences, d’infrastructures, de données gouvernées, de financements et d’une capacité de maintenance.

L’open source n’est pas une étiquette magique

Le débat devient confus lorsqu’on appelle « open source » tout ce qui peut être téléchargé. Il faut distinguer plusieurs réalités.

L’open source software n’est pas seulement un logiciel que l’on peut télécharger. Son code source doit être disponible dans une forme permettant la modification, et sa licence doit autoriser, sous certaines conditions, l’utilisation, la modification et la redistribution. Cette distinction évite de confondre accès technique et véritable liberté d’usage.

Les open weights sont les paramètres entraînés d’un modèle d’intelligence artificielle mis à disposition. Ils peuvent être téléchargés et exécutés localement, mais cela ne signifie pas que les données d’entraînement, le code complet, les méthodes de préparation ou toutes les conditions d’usage sont ouverts. Un modèle peut donc être disponible sans être totalement transparent. La définition de l’Open Source AI proposée par l’OSI va plus loin : elle associe les paramètres aux éléments nécessaires pour étudier et modifier réellement le système, notamment le code et les informations sur les données.

L’open data désigne des données réutilisables selon des règles définies. Des données publiques ouvertes ne doivent pas être confondues avec des données personnelles librement exploitables. Enfin, les open standards sont des formats et des interfaces qui permettent à plusieurs outils de communiquer.

Ces dimensions se complètent, mais aucune ne suffit seule : un logiciel ouvert dépend encore de ses données, de son infrastructure et de sa documentation.

Le premier travail consiste donc à cartographier les briques ouvertes, les propriétaires des données, leur lieu d’hébergement, les composants remplaçables et les personnes capables de corriger une vulnérabilité lorsque le fournisseur principal n’est plus disponible.

Le Maroc a commencé à faire de l’ouverture un sujet stratégique. Lors de la United Nations Open Source Week 2026, le ministère chargé de la Transition numérique a présenté l’open source comme un levier de transparence, d’explicabilité, de confiance et de souveraineté. Il rappelait aussi que l’ouverture exige compétences, infrastructures et gouvernance. La souveraineté ne naît pas d’un bouton « télécharger ».

La souveraineté n’est pas l’isolement

Parler de souveraineté numérique ne signifie pas que le Maroc devrait tout produire seul, fermer ses frontières technologiques ou remplacer chaque outil international par une copie nationale.

Un pays souverain n’est pas un pays isolé. C’est un pays capable de choisir ses dépendances, de les mesurer et de négocier avec elles. Il peut utiliser un modèle développé ailleurs, à condition de comprendre ses conditions d’usage, de protéger ses données, de conserver une solution de repli et de former les personnes capables de l’adapter.

J’appellerais cette approche une open sovereignty, ou souveraineté ouverte. Elle repose sur quatre capacités : comprendre les technologies, les adapter aux priorités locales, les héberger dans un cadre maîtrisé et contribuer à leur évolution. Elle accepte les partenariats internationaux, mais refuse que la compétence, la donnée et la décision disparaissent toutes au même endroit.

Cette vision rejoint Maroc Digital 2030 et la feuille de route AI Made in Morocco, qui placent la capacité de calcul, le Cloud, les talents et les usages nationaux au cœur de la transformation numérique. Elle est cohérente avec l’annonce de modèles capables d’identifier des variantes linguistiques et de transcrire la Darija. Leur valeur dépendra des équipes qui les évaluent, des données qui les améliorent et des services qui les intègrent.

Le cas d’une PME marocaine

Revenons à cette PME. Ses clients écrivent en français, en arabe, en Darija et parfois en espagnol. Ses collaborateurs consultent des contrats, des factures, des catalogues et des procédures internes. L’objectif n’est pas de remplacer leur jugement, mais de retrouver plus vite la bonne information et de préparer une première réponse, vérifiable avant son envoi.

La première option est une API propriétaire. Le déploiement est rapide : quelques appels réseau, une facture mensuelle et peu d’infrastructure à administrer. Mais chaque document envoyé crée un flux à documenter. Les réponses dépendent d’un service externe, les coûts varient avec le volume et la migration peut devenir complexe si les prompts, les formats et les mécanismes de sécurité sont spécifiques au fournisseur.

La deuxième option consiste à installer localement un modèle open-weight. Les documents sensibles restent dans un Cloud maîtrisé ou sur une infrastructure hybride. Un système de RAG (Retrieval-Augmented Generation) recherche d’abord les passages pertinents dans les documents de la PME, puis le modèle formule une réponse à partir de ces sources. La collaboratrice peut alors ouvrir le passage cité, vérifier la version du contrat et corriger la réponse avant de l’envoyer. La technologie ne remplace pas la décision ; elle raccourcit le chemin vers la preuve.

Mais cette architecture demande davantage qu’un téléchargement. Il faut choisir un modèle, vérifier sa licence, dimensionner les GPU ou le CPU, sécuriser les accès, mettre à jour les dépendances, surveiller les performances et organiser une procédure de reprise en cas de panne.

Une troisième voie consiste à construire une architecture hybride : les données sensibles et les fonctions critiques restent localement maîtrisées, tandis que certaines tâches non sensibles utilisent un service externe. Cette option peut offrir un bon compromis, à condition que la frontière entre les deux environnements soit documentée et contrôlée.

Architecture	Avantage principal	Risque principal
API propriétaire	Mise en œuvre rapide	Dépendance, coût variable et contrôle limité
Stack ouvert hébergé localement	Contrôle, adaptation et réversibilité	Besoin de compétences, de calcul et de maintenance
Architecture hybride	Flexibilité et résilience	Gouvernance et sécurité plus complexes

Dans les trois cas, la PME doit conserver ses données dans des formats exportables, documenter les interfaces et prévoir une solution de secours. Le choix ne devrait pas être « open source contre propriétaire », mais « quel niveau de contrôle est nécessaire pour chaque fonction ? »

Avant de choisir une architecture, cinq questions devraient être écrites dans le cahier des charges : les données peuvent-elles quitter le territoire ou l’organisation ? Le service reste-t-il utilisable si l’API externe devient indisponible ? Peut-on exporter les données, les prompts et les résultats dans des formats documentés ? Qui corrige une faille et dans quel délai ? Le budget inclut-il trois ans de maintenance, de supervision et de formation ? Ces questions déplacent la discussion du prix de départ vers la capacité à durer.

Le MLOps, c’est-à-dire l’organisation du cycle de vie des modèles, permet de suivre les versions, les données, les évaluations et les incidents. Le DevSecOps ajoute la sécurité au cycle de développement et de déploiement. Ces mots peuvent sembler éloignés des préoccupations d’une PME ; ils décrivent pourtant une question très concrète : qui sait ce qui a changé dans le système et qui peut revenir à une version sûre ?

Ce que l’ouverture peut réellement accélérer

Le premier bénéfice est la réduction du vendor lock-in. Un logiciel ouvert ne supprime pas tous les coûts de migration, mais il rend plus plausible le remplacement d’un prestataire. Des formats documentés, des API compatibles et une communauté active permettent à plusieurs entreprises de proposer des services autour de la même base.

Le deuxième bénéfice est l’adaptation aux usages marocains. Une solution générique peut mal traiter les noms locaux, les documents administratifs, la Darija, l’amazighe ou les échanges mêlant français et arabe. Une communauté locale peut corriger les erreurs, produire des jeux de tests et améliorer les outils selon les situations réellement rencontrées. L’ouverture rend cette adaptation possible ; elle ne la réalise pas automatiquement.

Le troisième bénéfice est l’audit. Lorsque le code, les configurations et les résultats d’évaluation sont accessibles, une université, une startup ou une équipe de cybersécurité peut examiner les choix techniques. L’audit n’est pas une garantie absolue, car il faut encore disposer de personnes capables de lire et de tester le système. Mais l’opacité n’est plus la seule option.

Le quatrième bénéfice est la création d’un marché de services local. Une PME n’a pas nécessairement besoin de développer son propre modèle. Elle peut avoir besoin d’un intégrateur marocain capable d’installer une solution, de la sécuriser, de la connecter à ses données et de l’assister pendant plusieurs années. L’open source déplace une partie de la valeur : du monopole sur la licence vers la compétence, l’intégration, la maintenance et la confiance.

Le cinquième bénéfice est la mutualisation. Une administration, une université et plusieurs PME peuvent financer un composant commun, partager un jeu de tests ou contribuer à un outil. Cette coopération compte particulièrement pour les langues et contextes peu représentés dans les grands jeux de données internationaux.

Ces bénéfices correspondent aux ambitions affichées autour d’une infrastructure nationale de données et d’IA. Mais ils ne seront réels que si les projets financent également la documentation, le support, la sécurité, la formation et la contribution en amont. Publier un dépôt vide ou un modèle sans guide d’utilisation ne crée pas un bien commun numérique.

Commencer par un pilote réversible

Une PME n’a pas besoin de remplacer toute son infrastructure pour tester une stratégie ouverte. Elle peut commencer par un périmètre à faible risque : rechercher une clause dans des documents non sensibles, classer des demandes de support ou proposer une réponse que l’employé valide avant envoi.

Le premier mois devrait inventorier les données, licences, flux réseau, dépendances et coûts. Le deuxième comparerait une solution propriétaire, une solution open-weight locale et une architecture hybride sur le même jeu de tests. Le troisième simulerait une panne, une migration et une fuite de données. Sans capacité de restauration et de récupération, l’équipe n’a pas gagné en souveraineté, même si le modèle fonctionne correctement.

Ce pilote doit mesurer la qualité, le coût par requête, la latence, la consommation de calcul, le taux d’erreur, le temps de reprise et le nombre d’intervenants compétents. La meilleure architecture ne sera pas forcément celle qui obtient le meilleur score de démonstration, mais celle que l’organisation peut expliquer, sécuriser et maintenir après le départ du prestataire.

Les limites qu’il faut regarder en face

Le code ouvert n’est pas gratuit au sens économique. Il faut payer les serveurs, le stockage, l’électricité, la supervision, les sauvegardes et les personnes qui interviennent lorsque le service tombe. Le Total Cost of Ownership, ou coût total de possession, peut être supérieur au prix initial d’une solution propriétaire si l’organisation sous-estime la maintenance.

Les modèles d’IA déplacent aussi la dépendance vers le matériel. Une PME peut contrôler le logiciel tout en dépendant d’un fournisseur de GPU, d’un Cloud ou d’une chaîne de distribution internationale. La souveraineté doit donc mesurer la chaîne complète : modèle, données, calcul, réseau, stockage, énergie et compétences.

L’ouverture ne garantit pas la sécurité. Il faut une software supply chain sécurisée, des mises à jour suivies et un SBOM (Software Bill of Materials), c’est-à-dire l’inventaire des dépendances et de leurs versions.

Les licences demandent également de l’attention : elles n’autorisent pas toutes les mêmes usages commerciaux, la redistribution ou la modification. L’équipe technique et le service juridique doivent vérifier ces obligations avant intégration.

Enfin, un modèle open-weight peut rester difficile à auditer. Sans données d’entraînement documentées, sans tests représentatifs et sans mesures de biais, l’accès aux paramètres ne suffit pas à comprendre les limites du système. L’ouverture doit donc être accompagnée d’une model card, d’un jeu de tests, de résultats reproductibles et d’un mécanisme de signalement des erreurs.

Sept conditions pour une souveraineté ouverte

1. Rendre la sortie possible. Privilégier les standards ouverts afin qu’une organisation puisse exporter ses données et changer de composant sans réécrire tout son système.

2. Mettre la réversibilité dans le contrat. Dans un marché public comme dans un contrat privé, il faut demander non seulement « combien coûte la première année ? », mais aussi « combien coûte la sortie ? »

3. Savoir ce qui est installé. Publier un SBOM et une documentation d’architecture. Ce qui n’est pas inventorié devient rapidement une dépendance invisible.

4. Financer le service après le prototype. Un outil critique sans équipe de support est une promesse fragile, même s’il est publié sous une licence ouverte.

5. Organiser la contribution. Universités, startups, administrations et entreprises ont besoin de règles de gouvernance, de responsables identifiés et de moyens pour examiner les contributions.

6. Investir dans les personnes. Cloud, cybersécurité, Data engineering, MLOps, licences et gestion de produits sont des compétences de souveraineté. La maîtrise ne réside pas uniquement dans le code.

7. Mesurer l’autonomie réelle. Les indicateurs peuvent inclure le temps nécessaire pour migrer, la part des composants remplaçables, la localisation des données, le délai de correction d’une vulnérabilité, le coût par requête, la disponibilité du service et le nombre d’équipes capables de maintenir la solution.

Cette grille éviterait de confondre une annonce et une capacité opérationnelle. Un pays ne devient pas souverain parce qu’un modèle est publié. Il le devient lorsque plusieurs équipes savent l’utiliser, l’évaluer, le sécuriser, le modifier et le remplacer.

Ouvrir, c’est aussi accepter la responsabilité

Le Maroc n’a pas besoin de tout produire seul. Il doit pouvoir comprendre, adapter, héberger, sécuriser et remplacer les technologies stratégiques qu’il utilise.

L’open source peut accélérer ce mouvement parce qu’il rend la coopération plus concrète. Il permet à une PME de commencer avec un composant existant, à une université de l’évaluer, à une startup de l’intégrer et à une administration de contribuer à son amélioration. Il peut transformer une dépense individuelle en capacité collective.

Mais cette promesse ne se réalisera pas avec des slogans. Elle exige des serveurs, de l’énergie, des données de qualité, des standards, des formations, des responsables de sécurité et des budgets de maintenance. Elle exige aussi d’accepter qu’une solution locale puisse être moins spectaculaire qu’une plateforme étrangère, mais plus contrôlable et plus durable.

La bonne question n’est donc pas : « Le Maroc peut-il se passer de toutes les technologies étrangères ? » Elle est plutôt : quelles dépendances voulons-nous accepter, lesquelles devons-nous réduire et quelles capacités devons-nous construire ensemble ?

L’open source ne promet pas l’indépendance absolue. Il offre quelque chose de plus utile : la possibilité de reprendre la main, progressivement, sur les couches qui comptent. À condition de ne pas oublier qu’un logiciel ouvert sans infrastructure, sans compétences et sans communauté reste seulement une possibilité.