API, modèle ouvert ou on-premise : comment choisir l'IA

Dans les réunions où l’on décide où rouler les modèles, la discussion part presque toujours du budget et se termine sur la sécurité, en passant par un tableau comparatif des performances qui sera obsolète d’ici six mois. C’est le moyen le plus fiable de prendre une décision qui sera à nouveau prise.

Les trois options disponibles présentent des profils de risque, de coût et de responsabilité tellement différents que les comparer sur un seul axe ne mène nulle part. Une API commerciale transfère la charge de l’infrastructure vers le fournisseur et conserve une contrainte de dépendance. Un modèle ouvert sur l’infrastructure gérée reprend le contrôle et transfère le travail à l’équipe. Une installation sur site maximise la gouvernance des données et introduit un engagement de capital et de compétences qui dure des années.

Le seuil de rentabilité évolue avec l’utilisation et non avec le volume

L’argument économique le plus utilisé en faveur de l’installation propre est qu’au-delà d’un certain seuil de volume, cela en vaut la peine. C’est vrai et cela doit être clarifié, car la variable qui détermine le seuil de rentabilité n’est pas la quantité totale consommée, mais la fréquence à laquelle elle est consommée.

Une infrastructure dotée d’accélérateurs dédiés paie à l’heure, qu’il s’agisse de traitement de demandes ou d’attente. Une charge répartie uniformément sur les vingt-quatre heures remplit cette capacité et rend le coût par opération très compétitif. Une charge concentrée sur trois heures de pointe, avec le reste de la journée sous 10% d’utilisation, paie la capacité inutilisée pendant 85% du temps et perd tout avantage, car il faut comparer le coût horaire de l’infrastructure et la dépense de consommation qui n’aurait été engagée que pendant les heures actives.

Le calcul du point mort doit donc être calé sur le facteur d’utilisation et non sur le volume mensuel. La bonne question est de savoir quel pourcentage de la capacité achetée sera réellement utilisé, et la réponse honnête, dans les organisations où les heures de bureau sont chargées, est presque toujours inférieure à 30 %.

Il faut ajouter l’élément que les comparaisons négligent le plus souvent : le coût des personnes. Une installation autogérée nécessite des compétences en optimisation d’inférence, gestion de la mémoire des accélérateurs, mise à jour des modèles, suivi de la qualité. Il s’agit de profils rares et coûteux, et dans de nombreuses organisations, le choix sur site s’est avéré intenable, non pas à cause du matériel, mais à cause de l’impossibilité de retenir ceux qui le faisaient fonctionner.

La résidence des données est une condition et non une préférence

Sur le plan des données, l’évaluation change de nature, car elle cesse d’être une optimisation et devient une contrainte. Certaines catégories d’informations ne peuvent pas sortir d’un périmètre défini, en raison d’obligations sectorielles, de clauses envers les clients ou de politiques internes qui ont la même force qu’une obligation.

Les questions à poser au fournisseur, avec réponse écrite dans le contrat, sont précises.

Où résident physiquement les données pendant le traitement et où, le cas échéant, sont-elles stockées ?
Combien de temps les journaux de requêtes restent-ils et qui y accède ?
Les données soumises sont-elles utilisées pour entraîner ou améliorer les modèles, et avec quel mécanisme d’exclusion ?
Quels sous-traitants sont impliqués dans la chaîne, par exemple pour la modération des contenus, et dans quelle juridiction opèrent-ils ?

Une précision qui évite les fausses appréciations : de nombreuses offres d’API commerciales d’entreprises garantissent une résidence européenne, l’exclusion des formations et une conservation limitée des journaux, ce qui entraîne un profil de conformité que certaines installations internes, gérées sans cryptage au repos et sans ségrégation d’accès, n’atteignent pas. L’emplacement physique des serveurs ne coïncide pas automatiquement avec la gouvernance des données, et une infrastructure mal gérée expose plusieurs services externes bien contractés.

Sur le plan réglementaire, ceux qui utilisent le système conservent les obligations établies par le cadre européen quelle que soit l’architecture choisie. Le devoir de surveillance humaine, de conservation des informations et des journaux n’est pas transféré au fournisseur car le modèle fonctionne sur son infrastructure.

Toute personne modifiant le modèle entraîne les obligations du fournisseur

Un aspect mal encadré de l’option poids ouvert concerne le changement de rôle. Par ailleurs, la norme ISO/IEC 42001 exige une diligence raisonnable et une contractualisation des responsabilités également envers les tiers qui fournissent les composants, y compris les modèles de base. Télécharger un modèle, l’adapter avec une formation supplémentaire sur vos propres données et le mettre en production sous votre propre marque fait évoluer l’organisation vers le rôle de fournisseur dans le cadre européen, avec l’ensemble des obligations documentaires qui l’accompagnent.

La distinction n’est pas purement formelle. Une adaptation légère, qui ne modifie pas l’utilisation prévue déclarée, reste dans le domaine d’utilisation. La formation qui modifie le comportement du système ou étend sa portée produit un nouveau système, dont l’organisation est responsable. Les entreprises qui ont investi dans l’adaptation de modèles ouverts sans évaluer cette étape se retrouvent obligées de reconstruire une documentation technique que personne n’avait prévue.

A l’inverse, les pondérations ouvertes offrent une garantie que les API n’offrent pas : le modèle validé reste le même, et aucune mise à jour du fournisseur ne modifie son comportement d’un jour à l’autre. Dans les processus soumis à validation formelle, où chaque changement nécessite une nouvelle qualification, cette stabilité vaut plus que toute différence de performance.

Quatre nœuds pour arriver à un choix défendable

L’arborescence suivante est parcourue dans l’ordre et chaque nœud exclut les options au lieu d’attribuer des scores.

Premier nœud, les données peuvent-elles quitter le périmètre ? S’il existe des catégories qui, par obligation, ne peuvent pas être traitées à l’extérieur, l’API publique quitte la table pour ces flux spécifiques, et ils restent une infrastructure gérée dans un périmètre contrôlé ou une installation propre. Si la contrainte n’affecte qu’une partie des cas d’usage, une architecture mixte est construite au lieu de pénaliser tout le reste.
Deuxième nœud, le comportement doit-il rester inchangé dans le temps ? Si le processus est soumis à des obligations formelles de validation ou de reproductibilité, un contrôle de version du modèle est nécessaire, ce qui exclut les API qui n’offrent pas de garanties de stabilité des versions.
Troisième nœud, quel facteur d’utilisation est réaliste ? Au-dessus de 60 % d’utilisation constante, l’infrastructure dédiée devient compétitive, en dessous de 30 % presque jamais. Entre les deux, la décision se déplace vers d’autres facteurs, et il est préférable de ne pas la forcer sur la question économique.
Quatrième nœud, les compétences existent-elles et peuvent-elles être conservées ? Une réponse négative à cette question annule les avantages théoriques des options autogérées, et il est préférable d’en discuter avec le responsable du personnel avant avec l’architecte.

La configuration que je vois le plus souvent travailler dans les moyennes et grandes organisations est mixte : API commerciale pour la plupart des cas d’utilisation, modèle ouvert sur infrastructure contrôlée pour les flux qui touchent aux données liées, avec une couche d’abstraction qui permet de déplacer un cas d’utilisation d’un endroit à un autre sans réécrire l’application. Cette couche coûte quelque chose à construire et redonne la liberté de changer d’avis, ce qui, dans un marché où les tarifs sont réduits de moitié tous les douze mois, vaut bien plus que l’optimisation des marges.