Faut-il déployer son modèle en interne ou en cloud souverain ?

Les trois facteurs de décision

Le débat « on-premise contre cloud » est souvent posé comme une préférence d’école. En production, il se réduit à trois facteurs, dans cet ordre.

La sensibilité des données. Un rituel qui manipule des dossiers de financement, des données de santé, des secrets industriels, des commentaires actuariels, n’a pas le même profil qu’un rituel qui classe des fiches produit publiques. La sensibilité n’est pas un sentiment DSI. C’est une classification : caractère personnel, secret des affaires, obligation de cloisonnement, conséquence d’une fuite. Plus la classification est haute, plus le périmètre d’exécution se resserre, et plus le nombre de sous-traitants acceptables diminue.

Les exigences de résidence. Contrats publics, doctrines sectorielles, politiques internes, localisations imposées par un régulateur : la donnée, et parfois le modèle, doivent rester dans un périmètre géographique et juridique. Un cloud dit souverain peut satisfaire la résidence sans satisfaire, à lui seul, la sensibilité : résidence n’est pas confidentialité. Un on-premise peut satisfaire les deux, s’il est réellement opéré, patché, journalisé. L’étiquette de l’offre ne clôt pas le facteur. L’écrit contractuel et l’exploitabilité le clôturent.

La capacité d’exploitation interne. Héberger un modèle, ce n’est pas le télécharger. C’est la GPU ou l’inférence, le scheduling, les mises à jour, les sauvegardes, le monitoring, les identités, les incidents de 3 h du matin, la compétence pour dire si une dérive vient du modèle ou des données. Une organisation qui n’a pas cette capacité et choisit l’interne n’a pas « repris le contrôle ». Elle a déplacé un risque fournisseur vers un risque d’exploitation non tenu. Une organisation qui a cette capacité et l’ignore paie parfois un cloud pour un confort qu’elle pourrait ne pas acheter. Le facteur est un inventaire de compétences et d’astreintes, pas une slide d’architecture.

Ces trois facteurs se combinent. Données très sensibles, résidence stricte, capacité d’exploitation réelle : l’interne (ou un tenant dédié chez le client) est souvent le seul point d’équilibre. Données moins sensibles, résidence UE, capacité d’exploitation faible : un cloud souverain opéré peut être le point d’équilibre. Les cas mixtes existent. Ils se tranchent par le rituel, pas par une politique unique pour « l’IA de l’entreprise ».

Un quatrième élément, parfois présenté comme un facteur, n’en est pas un : la préférence culturelle pour « avoir les machines chez soi ». Cette préférence peut coïncider avec les trois facteurs. Lorsqu’elle s’y substitue, elle produit des on-premise non opérés, ou des refus de cloud qui n’ont pas d’écrit de résidence pour les justifier. Le COMEX peut avoir une préférence. Le dossier de décision, lui, doit citer les trois facteurs. Sinon le choix n’est pas arbitrable l’année suivante, lorsque l’un des trois aura changé.

Ce que chaque option implique réellement

L’interne, bien fait, implique un socle : isolation, contrôle d’accès, traces, capacité à extraire et à quitter, personnel formé. Il implique aussi un rythme de mise à jour des modèles plus lent, ou plus coûteux, que celui d’un API publique. Ce n’est pas un défaut. C’est un profil. Les rituels qui exigent la stabilité de version s’en accommodent. Les expérimentations qui exigent le dernier modèle s’en accommodent mal. D’où l’intérêt de ne pas faire porter au même runtime l’expérimentation et le rituel de comité.

Le cloud souverain, bien choisi, implique un contrat de résidence, une lisibilité des sous-traitants, une politique d’entraînement (vos données ne nourrissent pas le modèle du fournisseur), un chiffrement, une réversibilité d’export. Il implique aussi une dépendance opérationnelle : l’incident, le changement de tarif, le changement de région. « Souverain » ne signifie pas « sans fournisseur ». Cela signifie un fournisseur dans un cadre juridique et territorial défini. Le cadre se lit. Il ne se déduit pas du mot.

L’hybride n’est pas une fuite. C’est souvent la configuration honnête : inférence interne pour les corpus classifiés, services cloud pour ce qui peut l’être, passerelle unique de gouvernance pour que le rituel ne voie qu’une exécution. L’hybride échoue lorsqu’il est un double standard : preuve et HITL d’un côté, chat nu de l’autre. Il tient lorsqu’il est un placement de moteurs derrière les mêmes artefacts de run.

Ce que chaque option n’implique pas, c’est la qualité de la décision. Un modèle interne mal validé produit un livrable indéfendable. Un modèle en cloud souverain, validé, sourcé, rejouable, entre en comité. Le lieu d’hébergement n’est pas un certificat de gouvernance. C’est un paramètre de risque. La gouvernance est dans le run.

Pourquoi la réversibilité prime sur le choix initial

Le facteur qui vieillit le moins bien, c’est le choix définitif. Les tarifs bougent. Les doctrines de résidence bougent. La capacité interne bouge (embauches, départs, fusions). Un rituel dont l’architecture est collée à un fournisseur, ou à un rack, devra être reconstruit le jour du changement. Un rituel dont l’architecture traite le modèle comme un moteur remplaçable changera de moteur.

La réversibilité se joue à plusieurs niveaux. Export des données et des artefacts de run. Indépendance des identifiants de décision vis-à-vis de l’API d’inférence. Images d’algorithmes versionnées. Absence d’entraînement sur le corpus client côté fournisseur, pour que partir ne soit pas un chantage aux poids. Contrats qui prévoient la sortie, pas seulement l’entrée.

Sans réversibilité, le premier choix devient une décision stratégique déguisée en choix technique. Les COMEX le découvrent tard, lorsque le coût de sortie dépasse le coût de rester. Avec réversibilité, le premier choix peut être imparfait. Il n’est pas une sentence. On peut commencer en cloud souverain le temps de monter une capacité interne, ou l’inverse, sans reprendre le rituel à zéro.

C’est pourquoi la question « interne ou souverain » est mal posée si elle est posée comme une fidélité. Elle est bien posée comme une politique de placement, révisable, pour chaque classe de données, avec une gouvernance de run identique.

Le model-agnostic en pratique

Être model-agnostic n’est pas collectionner les connecteurs. C’est faire en sorte que le livrable métier, la preuve, la validation et le coût par run ne dépendent pas du moteur. Le moteur est déclaré dans le Run Receipt. Il n’est pas l’identité du rituel.

En pratique, cela veut dire : une interface d’inférence interne à la plateforme, des évaluations de qualité par rituel (taux d’acceptation, pas benchmark public), un routage explicite (tel type de run, tel moteur), une capacité à figer une version pour les runs d’audit. On peut alors déplacer un rituel d’un cloud souverain vers un interne, ou changer de modèle, sans changer ce que le comité signe.

Les organisations qui construisent cette couche en interne le peuvent. Elles paient le délai et la maintenance d’un socle. Les organisations qui l’achètent le peuvent aussi, si le socle est réellement agnostique, et si la sortie est prévue. Celles qui lient chaque rituel à un notebook et à une clé d’API ne le peuvent pas. Elles n’ont pas un placement de modèle. Elles ont une collection de prototypes. Le jour où la résidence ou la sensibilité l’exige, elles recommencent.

Le choix interne / cloud souverain reste un choix sérieux. Il se tranche avec les trois facteurs. Il se survit avec la réversibilité. Sans le second, le premier est une photographie datée. Avec le second, il est une décision d’exploitation, que l’on peut revoir sans interrompre le rituel.

Les DSI qui documentent ce placement dans une note d’architecture d’une page : classe de données, résidence, opérateur, clause de sortie, moteur déclaré dans le Run Receipt : ont un objet à faire signer. Celles qui n’ont qu’un positionnement de principe (« on est souverain » / « on est interne ») n’ont pas d’objet. Le jour où un rituel nouveau arrive, avec une sensibilité différente, la note d’une page se met à jour. Le principe, lui, force à tout traiter de la même manière. C’est rarement le bon traitement.