Bintou Boïté (CNAM) : « pour exercer réellement des choix, il faut avoir la capacité de choisir »

La CNAM est la « tête de réseau » opérationnelle de l’Assurance Maladie, pour les salariés comme pour les indépendants. Nos missions principales comportent évidemment la gestion de la protection sociale maladie. Cela inclut l’affiliation des assurés sociaux et la gestion de leurs droits. Nous procédons donc aux remboursements des frais de santé, qu'ils soient des soins de ville ou en hôpital, le traitement des  revenus de remplacement (indemnités journalières en cas de d’arrêt de travail, rentes invalidité…), etc.

Nous sommes donc en relation avec les assurés sociaux, les professionnels de santé (libéraux ou en établissements), et les employeurs. Les professionnels de santé adressent des factures que nous réglons directement ou bien dont nous remboursons le montant aux assurés. Côté employeurs, nous devons avoir des informations complémentaires à ce qui nous parvient par la DSN (Déclaration Sociale Nominative) mensuelle gérée par le GIP-MDS et, en cas de subrogation, nous leur versons les indemnités journalières. Ces échanges-là se font de plus en plus par ce qu’on appelle les signalements DSN événementiels, donc l'employeur déclare que son salarié s’est arrêté et renseigne les modalités précises de cet arrêt.

La CNAM est un organisme de droit public. A l’inverse, les caisses d’assurance maladie (CPAM) et les caisses générales de sécurité sociale en Outre Mer sont des organismes de droit privé chargés d’un service public répartis sur l’ensemble du territoire. Il en existe plus d’une centaine. Ces organismes sont dotés d'une personnalité morale. L’Assurance Maladie n’est pas un organisme central avec des agences déconcentrées mais la CNAM assure bien la tutelle de l'ensemble, tutelle fonctionnelle, tutelle budgétaire aussi, et puis tutelle réglementaire sur les règles qui s'appliquent à tous. Chaque CPAM dispose d’un conseil  (Instance représentative des partenaires sociaux), ce qui lui permet de décliner localement la politique nationale, de rester proche des réalités locales avec une certaine marge et une certaine latitude de décision. Et chaque CPAM a une relation de proximité avec les professionnels de santé de son territoire. Cette proximité a été très utile pour gérer la crise sanitaire Covid-19.

L’Assurance Maladie compte environ 82 000 collaborateurs dont moins de 3000 à la CNAM.

Les équipes informatiques de la CNAM pilotent l’IT de l’ensemble de l’assurance maladie. Nous couvrons ainsi l’ensemble des activités liées à l’IT.

Une partie importante de notre activité, c’est évidemment la production et l’exploitation de notre système d'information métier. Nous devons faire en sorte que, quoiqu’il arrive, les prestations soient payées, que les assurés soient affiliés, etc. Ce travail quotidien (j’insiste sur « quotidien ») est le socle de tout. Nous traitons chaque jour six millions de factures (les feuilles de soins), à 95 % en nativement dématérialisées via le système SESAM-Vitale, le solde étant en feuilles de soins papier. A ces six millions, il faut ajouter les paiements aux hôpitaux, les indemnités journalières… Avec des cycles mensuels, il y a d’autres paiements comme les rentes invalidité.

Nous opérons également des téléservices. Le plus connu est le compte Ameli. Il y a 45 millions d’assurés disposant d’un compte qui réalisent 1,5 million de connexions par jour. Le deuxième bouquet de téléservices est celui destiné aux professionnels de santé, Amelipro : prescrire un arrêt de travail en ligne, mettre en place un protocole de soins électronique en ligne, vérifier les droits des assurés…

Même si nous recevons les données de base de manière nativement dématérialisée, ces données doivent être traitées pour aboutir à une décision de remboursement ou de versement (en fonction des droits afférents à chaque assuré) puis au virement correspondant.

Notre production est en croissance de l’ordre de 3 à 4% chaque année. Et si j’ai insisté sur « quotidien », c’est parce que, vus les volumes, il est impossible de reporter au lendemain ce qui n’aurait pas été fait un jour. Sur de tels volumes, les stocks s’empilent très vite et ça peut devenir rapidement ingérable.

La deuxième partie de notre activité, c’est bien sûr la gestion des outils qui permettent aux plus de 80 000 collaborateurs de travailler.

Nous avons évidemment des contraintes assez fortes en matière de SLA. Nous avons des obligations de permanence du service public. Le compte Ameli doit rester ouvert et accessible. Et si un professionnel fait une télétransmission, c’est tout de suite. Ca doit marcher immédiatement. Notre disponibilité est proche de 99,9 % et nous cherchons toujours le 100 %.

Tout le système d’information métier est géré sur nos propres infrastructures. Nous hébergeons donc nos applications cœur de métier et les téléservices. Nous avons six bâtiments de datacenters dans quatre villes. Quatre sur six sont entièrement dédiés à la production et cela nous permet de gérer notre PCA/PRA avec une réplication actif-actif et une duplication permanente (avec un léger décalage pour l’une des villes un peu éloignée).

Avec cette approche, nous sommes maîtres de notre destin.

Derrière, nous avons évidemment des équipes techniques, des architectes techniques, des ingénieurs réseau, etc. qui construisent nos infrastructures pour que tout fonctionne.

Nous avons à peu près 5000 composants qui constituent notre système d'information avec plus ou moins 700 sous-systèmes. Entre ceux-ci, nous avons 12 000 flux d’échanges par jour. Certaines briques d’échanges peuvent supporter vingt millions d’appels par jour, cela tous les jours.

Pour faire évoluer notre patrimoine applicatif, nous avons une roadmap applicative qui est, en 2026, de l’ordre de 240 000 jours.hommes. C’est de l’ordre de 20% du parc applicatif qui bouge chaque année. 99% de notre roadmap d'évolution correspondent à la prise en compte de décisions réglementaires, législatives ou issues des négociations conventionnelles.

A l’Assurance Maladie, tous les chiffres sont rapidement impressionnants… D’autant que le côté quotidien est très structurant.

Le deuxième aspect de notre SI est son côté parfois ancien. Nous avons une dette technique avec des strates. Nous consacrons chaque année 12 % de la feuille de route au traitement de la dette technique. Pour éviter que l’on néglige cette part au nom de priorités fonctionnelles plus urgentes, elle est sanctuarisée en dehors de la feuille de route projets.

Nous avons en effet des serveurs X86 et des baies Hitachi. La production représente environ 17 Po de données. Le Legacy repose sur environ 25 000 instances VMware.

Nous avons également construit un cloud privé avec une technologie conteneurs classique, en l’occurrence avec Openshift de Red Hat. Nous sommes en train de basculer nos téléservices sur ce cloud privé et d’y monter quelques applications back-office, notamment autour de la gestion des pensions d'invalidité et des rentes.

En tant qu’opérateur public, nous avons à appliquer la doctrine « Cloud au centre ». Et c’est donc important que nous ayons un cloud privé. Un des axes majeurs d’une véritable indépendance numérique c’est d'être capable de pouvoir exercer véritablement des choix. Et pour exercer des choix, il faut avoir la capacité de choisir. Avoir un cloud privé, cela veut dire que l’on maîtrise la technologie, qu’on en comprend les enjeux et qu’on a le choix entre son propre cloud et, le cas échéant, un cloud externe. On peut décider en fonction des volumes, de la complexité, etc. Nous récupérons ainsi la capacité de choisir sans être contraint  

Nous avons construit notre cloud privé, avec les équipes de la CNAM. Ce qui contribue aussi à notre indépendance, c’est que nous avons ainsi les compétences en interne. Nous sommes montés en compétences autour du Cloud. Si, un jour, nous estimons préférable d’utiliser un cloud externe, nos équipes sauront de quoi elles parlent, elles connaissent les dangers, elles savent ce qu’il faut regarder, elles savent quelles sont les bonnes questions à poser.

C’est aussi une bonne façon de ne pas regarder passer les trains technologiques. Nos équipes se les approprient. Cela permet de rééquilibrer la relation avec les fournisseurs. Aujourd'hui, le cloud est actif, il est rentré en production. Une équipe de 40 personnes assure le fonctionnement du cloud et son maintien en conditions opérationnelles. Je souhaitais que le Cloud soit abordé comme une technologie et non pas comme une filière. Cette équipe est aussi en charge de toute la brique d’intégration et de déploiement automatique, y compris pour les produits Legacy.

Compte tenu de notre taille, nous travaillons évidemment beaucoup avec des briques techniques transverses qui sont partagées. Et quand nous construisons une brique transverse, j’ai demandé à ce qu’elle soit compatible aussi bien avec les instances classiques VMware qu’avec les conteneurs du cloud privé.

Avant que nous commencions à construire le cloud privé, il y avait une filière digitale qui était le précurseur de cette plateforme cloud. C’était notre première expérimentation et elle a permis d'accélérer un certain nombre de choses. Mais l’équipe responsable avait construit son propre socle technique, non-compatible avec les choix qui étaient faits sur le reste du SI. Nous avons changé cela en basculant sur le cloud.

Nos rapports avec eux se sont tendus… Mais nous étions dans une situation un peu particulière par rapport à d’autres organisations.

Nous avions un marché signé pour trois ans pour un certain nombre de licences perpétuelles. Toutes avaient été payées en début de marché mais pas activées en même temps. La dernière année du marché, l’an dernier, nous avons voulu débloquer nos dernières licences perpétuelles. Et VMware nous a répondu que les licences perpétuelles -que nous avions payées- n’existaient plus, qu’il fallait passer au mode souscription.. Il s’agissait simplement pour nous, d’obtenir ce qui avait été payé. Je ne peux même pas dire qu'il y a eu un bras de fer parce que, en réalité, VMware a joué la montre. Puis nous les avons finalement informés que nous allions demander l’application pure et simple du contrat devant le tribunal. Ils ont essayé de nous convaincre de renoncer en proposant des « conditions avantageuses ». Mais, à mes yeux, cela ne pouvait que concerner l’avenir, l’évolution de l’existant. Je souhaitais obtenir ce qui était prévu dans le marché. Nous avons introduit un référé. Quand ils ont compris que leur position était intenable, ils ont rouvert leur serveur et nous ont livré nos licences perpétuelles sur le fil du rasoir, le 25 décembre...

Sortir de 25 000 instances VMware, cela ne se fait pas aisément. Mais suite à cette confrontation, nous nous sommes tournés vers l’achat de licences perpétuelles d’occasion, que l’on peut trouver facilement sur le marché  ce qui nous a permis de couvrir l’évolution des 18 prochains mois. Nous avons également trouvé, sans difficulté, des sociétés qui assurent le support Vmware. Nous n’avons à la suite de cette opération rien versé à VMware l’an dernier et cela nous est aussi revenu beaucoup moins cherque ce que nous aurions payé avec un support de l’éditeur. Sans oublier le surcoût qu’aurait représenté le passage en mode souscription. Et 18 mois, c’est un délai suffisant pour travailler sur une sortie.

A date, je ne sais pas ce que nous allons faire en définitive.

Nous avons une solution alternative à VMware : Proxmox Virtual Environment (PVE), une plateforme de virtualisation open-source, éditée par l’Allemand Proxmox Server Solutions GmbH. Mais si nous basculons toutes nos instances, qu’est-ce qui peut nous garantir que, demain, l’éditeur existera toujours ou qu’il ne sera pas racheté par un acteur américain ou autre ? Ou que les conditions commerciales resteront les mêmes ? Par les temps qui courent, est-il raisonnable de ne disposer que d’une solution d’un seul éditeur sur un besoin donné ?

Ma stratégie s’oriente plutôt sur, toujours, cette idée qu’il faut garder son indépendance, sa capacité à réagir si un éditeur nous faisait faux bond. Peut-être faut-il envisager de répartir les actifs entre plusieurs technologies et plusieurs fournisseurs : du Proxmox, du VMware… Le problème est bien que, aujourd’hui, nous avons un fonctionnement extrêmement monolithique, un outil par besoin.

Parce qu'il faudrait réécrire tout le patrimoine applicatif Legacy pour le rendre compatible avec le cloud. Ça voudrait dire par exemple conteneuriser les applications  de gestion des indemnités journalières ou de gestion des frais de santé, tout en maintenant, sans rupture, la production quotidienne et en assurant l’évolution du système d’information (20% du parc applicatif évolue chaque année). On parle de dizaines de millions de lignes de code ! C’est absolument impossible, même avec de l’IA.

En plus, nous sommes astreints à certifier nos applications pour certifier nos comptes. Une transformation des applications, au-delà du développement, supposerait aussi des campagnes de tests colossales. Et tout ça à périmètre constant, sans aucune évolution fonctionnelle. Une migration de l’ensemble du parc applicatif sur le cloud serait donc couteuse en argent, en délai pour un gain non démontré aujourd’hui. Nous restons un acteur avec de fortes contraintes budgétaires et utilisant de l’argent public.

En revanche, nous décidons  de démarrer un certain nombre d’applications directement sur le Cloud. Ou au cas par cas, on peut décider de migrer du Legacy vers le Cloud quand ça se justifie.

Aujourd’hui, pour le Cloud, nous utilisons Openshift de Red Hat. Nous allons sans doute chercher un autre acteur, européen. Mais cet acteur restera-t-il européen demain ou après-demain ?

Nos approches sont variables selon les cas. Beaucoup de composants du SI, même sur les fonctions supports, sont développés en interne. Toute la gestion comptable (générale et auxiliaire), baptisée Copernic, a été développée par la CNAM pour l’ensemble de l’Assurance Maladie, CNAM et CPAM. La paye, qui couvre aussi d’autres fonctions de gestion des ressources humaines (entretiens d’évaluation, formation…), est un applicatif mutualisé qui a été développée par la CNAF (Caisse Nationale d’Allocations Familiales). D’autres mutualisations sont opérées avec l’URSSAF Caisse Nationale ou d’autres organismes de la sphère sociale.

Nous utilisons aussi des progiciels par exemple pour les achats de la CNAM qui sont gérés sur un système baptisé Simba, une version de SAP en cours d’évolution vers .du S/4Hana. De même, pour la gestion des plateformes téléphoniques, la gestion des mails, etc. nous utilisons des solutions du marché clés en mains.

L’achat des PC est réalisé avec des marchés nationaux pour l’ensemble de l’Assurance-Maladie. Mon prédécesseur, Alain Issarni, avait choisi la bureautique Microsoft sur la base de licences Office 2016 d’occasion. on premise. qui ne nous coûtaient pas grand-chose. Mais, en 2025, le support d’Office 2016 s’arrêtait. Nous avons entamé une évolution en deux axes. Renouveler Office mais engager dès maintenant les premières opérations de mises en place de solutions plus souveraines.

D’abord, nous sommes obligés de conserver du Office, en particulier Word et Excel. Certaines applications cœur de métier, par exemple, lancent Word pour créer des courriers. Cela concerne 60 à 70 % des collaborateurs ! Est-ce que cela a du sens de vouloir sortir d’Office dans ces conditions si on devait de toutes façons l’installer sur la majorité des postes de travail ? A l’époque de la création du Legacy, c’était normal d’appeler Word pour écrire des courriers. La sortie d’Office passe donc par une réécriture préalable de ces fonctions. Pour remplacer Office 2016, nous avons donc acheté des licences Office 2024 et non de la souscription Office365. Nous achetons des licences perpétuelles et il ne peut donc pas y avoir, après coup, d’augmentations de tarifs et le coût de revient est réparti sur l’ensemble du temps de possession. Plus nous gardons un logiciel, moins il est coûteux à l’année. Et nous installons on premise. Avec Office 2024, j’ai jusqu’à 2030 pour gérer notre sortieCes actions de réécriture seront inscrites dans notre roadmap 2027.

Dans d’autres cas, nous avons une approche différente. En parallèle, notre solution visio utilise Zoom.Nous avions déjà écarté Teams Nous avons commencé un pilote avec les outils de la DINUM, Visio et Tchap, et notre objectif est de les généraliser en 2027 aux 80 000 agents de l’assurance maladie.

Cela dit, il est tout à fait possible de conserver quelques licences Zoom pour certains usages, par exemple lorsque l’on fait des webinaires à 15 000 participants. Et c’est la même chose pour Office. D’ailleurs. si nous basculons vers une autre solution, il restera possible d’acquérir quelques licences pour les quelques cas où le remplacement ne serait pas possible ou aisé. Je pense à certains contrôleurs de gestion qui ont des macros Excel qui ne peuvent pas être migrées aisément.

La relation fournisseur n’est pas la même quand vous  avez 80 000 licences ou lorsque vous avez une solution pour la grande majorité et quelques licences pour des usages spécifiques. Le prix n’est pas non plus le même. Dans mon cas personnel, je n’ai absolument pas besoin d’Office 2024 et un logiciel libre me conviendrait tout à fait. Agir ainsi me paraît être un moyen assez pragmatique de pouvoir introduire de la souveraineté sans que les utilisateurs aient l’impression d'une régression.

Notre approche implique en effet un sujet de fond. Aujourd’hui, le poste de travail est identique, avec les mêmes outils, du technicien au directeur général. C’est beaucoup plus simple en termes de gestion des plateformes, gestion des mises à jour, gestion des configurations. Si on commence à dire qu’on a des postes différents selon les métiers, par exemple, ça veut dire que la DSI doit s’adapter pour gérer des configurations différentes, donc peut-être avec des compétences différentes. C’est comme avoir du Proxbox à côté de VMware et d’autres plateformes. Il y a forcément une certaine complexité induite. Et des besoins de formations, peut-être des formations différenciées. Mes équipes doivent-elles devenir multi compétences ? Comment assurer cette transition, les formations nécessaires, la continuité de service et l’organisation  du travail des équipes si tous n’ont pas les mêmes compétences ?

Il nous faut construire une feuille de route d’évolution vers des outils souverains qui intègrent de manière assez forte, dès le début, les contraintes organisationnelles, de formation et d’évolution des équipes pour que ça ne soit pas juste un coup d’épée dans l’eau. Par ailleurs, la tentation du « je ferme et je bascule », de quitter un éditeur pour un autre, cela ne change rien en termes d’indépendance puisqu’on est toujours sous la dépendance d’un éditeur spécifique.

La priorité de tout service public, c’est la continuité de service. Et, donc, en effet, comment on doit gérer ce nouveau risque qui est apparu récemment, qui est celui de la rupture numérique de longue durée pour des motifs qui ne sont pas des motifs techniques. Si on nous dit « vous n’avez plus le droit de travailler avec Oracle », est-ce que cela doit signifier de ne plus payer les indemnités journalières ou les frais de santé ? Evidemment, c’est impossible.

Notre première action sur ce sujet, c’est de cartographier nos dépendances. Et d’analyser les conséquences de chaque dépendance sur la continuité d’activité. Est-ce que nous sommes capables de fonctionner en mode dégradé sans tel ou tel outil?

Mon prédécesseur Alain Issarni avait déjà migré la plupart de nos bases Oracle vers du PostgreSQL. La règle posée était que, en deçà d’une certaine taille, c’était nécessairement du PostgreSQL, au-delà de l’Oracle. Dans le prolongement, nos architectes adaptent aujourd’hui de plus en plus l’architecture technique pour que les bases de données trop grosses soient coupées en bases plus petites afin de favoriser davantage PostgreSQL.

En effet, vous pouvez noter que les équipes de la DSI sont excellentes avec un très haut degré d’expertise. !.

Ils ont tout de même monté un cloud, par eux-mêmes. Ils ont développé des architectures d'intelligence artificielle on-premise, . Ils se font aider, mais tout de même, ils maîtrisent le sujet. Ils ont aussi repris la gestion d'une plateforme interne data qui gèrent de la donnée déstructurée. Quand on leur permet de commencer à s'approprier une technologie, vous trouvez des gens qui réussissent à construire quelque chose. Et qui marche.

Parfois, cela a été dans la douleur, c’est vrai. Mais le cloud a été monté en moins de deux ans. Quand je suis arrivé, ils m’ont dit « on peut avoir un cloud Platform as a Service ». Et ils l’ont fait. Fin 2025, nous avons déployé sur ce cloud interne une application cœur de métier qui gère les règles récentes en matière de convention médicale, et notamment des échanges assez importants de données entre la partie informationnelle et la partie production pour mettre à disposition des professionnels de santé des indicateurs d’activité sur leur patientèle qui servent à définir une rémunération. Inutile de dire qu’il s’agissait d’une application très importante. Et nous l’avons mise sur le cloud avec succès. Nous sommes donc désormais capables de développer directement pour le Cloud des applications destinées à remplacer ou compléter du Legacy.

Avoir de telles compétences en interne, c’est pour moi une des clés de l’indépendance et de la capacité de faire des choix.

Peut-être qu’un jour nous ferons de l’hybride avec du cloud public ou externe. Mais nos équipes internes auront les compétences nécessaires. Quand on débute, il est plus facile de faire comprendre aux métiers que ça va peut-être être un peu difficile  au début. Mais cela permet aux équipes internes d’acquérir les compétences, de confronter leurs approches théoriques à la pratique.

Quand mes équipes parlent du Cloud ou de l’IA, elles savent de quoi elles parlent.

Pour commencer, le directeur général,  a créé auprès de lui une mission IA générative. chargée de cadrer la manière dont l’IA sera être utilisée au sein de l’Assurance Maladie.: Nous voyions bien que l’usage de l’IA commençait à s’étendre, y compris dans le réseau des CPAM. Nous voulions également respecter des principes de souveraineté. Nous nous sommes donc orientés vers des modèles de Mistral.ai.

Et, fidèles à notre logique de « on n’est jamais mieux servi que par soi-même », nous avons décidé d’installer ces modèles chez nous. Donc nous avons acheté des serveurs et des GPU fin 2024. Et nous avons ensuite défini des chartes éthiques, des chartes d’usage… Nous avons aussi mené des opérations de formation et d’acculturation. Autour de cas d’usages, nous avons créé des bases de prompts pour créer des contenus avec de l’IA générative, installé des assistants, déployé du RAG… Tout cela est, finalement, assez classique.

Dans un premier temps, nous avons déployé 4 GPU puis 12, 20 et aujourd’hui 50.

Nos équipes ont progressé au même rythme. Ils ont commencé avec des outils pour 4 GPU puis ils ont reconstruit toute l’architecture pour améliorer les temps de réponse des modèles quand le nombre de GPU a monté.

Nous arrivons à un stade où, d’ici la fin de l’année, l’IA interne devrait être ouverte à 20 000 personnes. Avec des modèles Mistral.ai hébergés on premise, non-connectés à Internet, avec le choix délibéré d’une absence d’entraînement.

Nous commençons à avoir des usages lourds. Par exemple créer de la documentation métier mise à disposition des agents ou faire un rapport de synthèse qui va être utilisé dans la lutte contre la fraude. Nous menons des expérimentations en matière de speech-to-text. Nous avons déjà des services de chatbot qui tournent.

Comme vous voyez, c’est plutôt une IA de productivité au quotidien, d’assistance des agents, posée à côté du SI.

Nous avons commencé à regarder l’IA agentique mais nos équipes ont constaté que, tant que tout notre contexte n’a pas été inclus, cela nous fait plutôt perdre du temps. C’est la même chose pour générer du code avec le soutien de l’IA en respectant les règles d’architecture ou de sécurité. Générer du code dont on ne peut rien faire, ça n’a aucun sens. Si le code généré est non-validé, il ne pourra être mis en production car on risque de nous refuser la certification de nos comptes. Et il faut également garantir ce respect des phases de contrôle et validation pour les codes issues des CPAM en restant être vigilants vis-à-vis du shadow AI. Cela implique que le cadre normatif soit suffisamment clair et fort.

La fausse promesse d’une sorte de démocratisation où tout le monde pourrait faire tout et n’importe quoi grâce à l’IA constitue un véritable risque. Qui va contrôler ? Qui va certifier ? Comment ? C’est un des  enjeux des prochains mois parce que nous n'avons pas beaucoup de temps, je pense.

Un autre enjeu, c’est l’achat de GPU. D’abord, il y a la question du prix avec des augmentations démentielles. Certains tarifs ont augmenté de 500% depuis l’an dernier ! Sans compter l’extrême vitesse d’évolution technologique, un modèle remplaçant l’autre en quelques mois. Alors, chaque changement de modèle amène des performances bien supérieures, c’est vrai. Mais la CNAM n’est pas le CEA ! Nous ne faisons pas des calculs mathématiques aussi complexes. Nous confions plusieurs documents à l’IA et nous lui demandons une synthèse : il ne faut pas exagérer non plus ! Nous n’avons pas forcément besoin d’être sur la dernière génération de GPU!

Le modèle « on premise » se heurte ainsi très vite au coût d’investissement. Par exemple, si l’on monte de 20 000 à 80 000 utilisateurs, il faudrait acquérir 200 GPU. Il est probable que l’on hybridera notre IA et qu’on louera des tokens à l’extérieur pour certains usages, sur un cloud externe. L’idée sera alors d’en profiter pour ouvrir sur ces usages non-sensibles à d’autres moteur que Mistral et, de fait, ouverts sur Internet.