UGAIA / AFEES · OUTIL
COMPAGNON DU TOME 2
Macro-modèle de choix du SLM souverain
Fonctions,
présentation et mode d'emploi
Version 2 — juillet 2026 · Ubuntu + Ollama
+ Mistral / Phi-4 / Llama
|
RÉSUMÉ COMEX Le macro-modèle transforme le fil
directeur du Tome 2 en un outil de décision opérable en moins de deux
minutes, par un DSI comme par un membre du COMEX. Quatre questions — classification des
données, usage, matériel, profil — convergent vers un « Passeport de choix »
: un modèle, sa commande de déploiement, son routage LiteLLM et son
rattachement au framework des cinq piliers. Un second module chiffre le point
d'équilibre entre API mesurée et infrastructure amortie. Les hypothèses par
défaut reproduisent le TCO du chapitre 17 : équilibre atteint à 15,2 mois
pour un usage conversationnel, 4,7 mois dès que l'usage devient agentique. Un troisième module exporte la figure
légendée destinée au manuscrit, en vis-à-vis du logigramme (Figure 41). L'outil ne remplace ni l'AIPD, ni
l'audit de sécurité, ni la validation par le Comité de Souveraineté IA. Il
documente une décision ; il ne la signe pas. |
Sommaire
Partie A — Présentation : les fonctions du
macro-modèle
A.1 Le principe : un
raisonnement à quatre étages
A.2 Les fonctions du module 1 :
le Passeport de choix
A.3 Les fonctions du module 2 :
le calculateur de break-even
A.4 Les fonctions du module 3 :
l'export pour le manuscrit
Partie B — Mode d'emploi
B.1 Ouvrir et diffuser l'outil
B.2 Module 1 : obtenir le
Passeport de choix
B.3 Module 2 : chiffrer le
point d'équilibre
B.4 Module 3 : exporter la
figure
B.5 Points de vigilance
Partie A — Présentation : les fonctions du
macro-modèle
Le Tome 2 contient déjà toute la matière
nécessaire au choix d'un modèle de langage souverain : la méthode des trois
questions du chapitre 10, l'arbre de décision express de l'annexe 2, la
classification N1-N4 et son routage par LiteLLM Proxy, la grille de sélection
pondérée, enfin les recommandations par profil d'organisation. Cette matière
est toutefois dispersée entre un chapitre, une annexe et deux logigrammes. Le
macro-modèle la rassemble en un raisonnement unique et vérifiable.
Sa raison d'être tient en une phrase : le
foisonnement des modèles open source rend le choix anxiogène, alors que trois
variables suffisent à le trancher. L'outil rend ces variables explicites, les
ordonne, et documente la décision qui en découle.
A.1 — Le principe : un raisonnement à
quatre étages
Le macro-modèle n'est pas un comparateur de
modèles. C'est une chaîne de contraintes, dans laquelle chaque étage restreint
le champ ouvert par le précédent. L'ordre n'est pas arbitraire : il reproduit
la hiérarchie de décision de l'ouvrage, où la souveraineté prime sur la
performance, et la performance sur le coût.
Figure 42 — Macro-modèle de choix du SLM souverain : quatre étages de décision. La classification des données pose le verrou ; l'usage et le matériel désignent le modèle ; l'arbitrage FinOps fixe le moment du basculement.
|
Étage |
Question posée |
Effet sur la décision |
|
1 — Souveraineté |
Quelle classification N1-N4 ? |
Pose le verrou. N3/N4 imposent l'inférence
locale et ferment la voie cloud, quel que soit l'argument économique. |
|
2 — Usage |
Conversation, code, STEM, RAG ou généraliste
? |
Désigne la famille de modèles pertinente. Un
modèle de code n'est pas un modèle de raisonnement. |
|
3 — Matériel |
PC 16 Go, serveur GPU 24 Go, ou cluster ? |
Borne le choix avant tout le reste. Le
matériel disponible écarte mécaniquement les modèles hors gabarit. |
|
4 — Profil |
TPE-PME, ETI, grande entreprise ou secteur
régulé ? |
Cadre l'échelle : déclenche les prescriptions
de durcissement et ouvre l'arbitrage FinOps. |
A.2 — Les fonctions du module 1 : le
Passeport de choix
À l'issue des quatre questions, l'outil ne se
contente pas de nommer un modèle. Il produit une fiche de décision — le
Passeport de choix — dont chaque rubrique répond à une question qu'un auditeur,
un DPO ou un membre du COMEX est susceptible de poser.
|
Fonction |
Ce qu'elle produit |
Utilité en gouvernance |
|
Recommandation principale |
Modèle, taille, empreinte mémoire, éditeur et
licence. |
Alimente la Model Card exigée par le pilier
P2 (documentation technique). |
|
Commande de déploiement |
Ligne Ollama exacte, quantification comprise,
copiable en un clic. |
Supprime l'ambiguïté du tag : « ollama pull
mistral » ne télécharge pas la dernière génération. |
|
Routage N1-N4 |
Règle de routage LiteLLM correspondant à la
classification. |
Matérialise le pilier P3 (gouvernance des
données) et la traçabilité mlflow_run_id. |
|
Justification |
Trois à quatre motifs explicites du choix
retenu. |
Constitue la trace du raisonnement, opposable
en audit. |
|
Alternative |
Modèle de repli et sa logique (socle EU,
filet de sécurité). |
Documente la réversibilité, critère du
Passeport de Souveraineté. |
|
Palier |
Niveau I, II ou III de montée en gamme. |
Traduit la règle d'or : commencer petit,
mesurer, puis monter en gamme. |
|
Rattachement |
Renvois aux chapitres, annexes et piliers
concernés. |
Relie la décision opérationnelle au framework
des cinq piliers. |
|
Durcissement |
Prescriptions déclenchées par le profil
(vLLM, NGINX, LDAP/SSO). |
Rappelle que le port 11434 ne doit jamais
être exposé. |
Trois règles d'arbitrage
codées dans le moteur
• Le socle européen par défaut. Mistral est retenu comme
base ; Phi-4 sert les petites configurations ; Llama 4 joue le filet de
sécurité lorsqu'un besoin n'est pas couvert. En secteur régulé, le moteur
ré-arbitre automatiquement vers Mistral et bascule Phi-4 en alternative.
• La spécialisation prime sur la polyvalence. Pour le code,
Codestral est préféré à Phi-4, conformément à la mise en garde du livre : Phi-4
excelle en RAG et en raisonnement, pas en génération de code.
• La souveraineté tranche en dernier ressort. Lorsque la
classification est N3 ou N4, aucun argument de coût ou de performance ne peut
rouvrir la voie cloud.
A.3 — Les fonctions du module 2 : le
calculateur de break-even
Le chapitre 17 pose la question dans les
termes exacts d'un COMEX : préférez-vous louer l'IA à chaque utilisation, ou
investir dans votre propre capacité de production ? Le module 2 y répond par un
chiffre unique — le nombre de mois au terme desquels l'infrastructure
souveraine devient moins coûteuse que l'abonnement.
Ses hypothèses par défaut ne sont pas
génériques : elles reproduisent le TCO à trois ans du chapitre 17, pour
cinquante utilisateurs. Le calculateur restitue 45 083 € de coût cloud annuel
contre 94 000 € de TCO local sur trois ans, et un point d'équilibre à 15,2 mois
— soit exactement la fourchette de douze à quinze mois annoncée dans l'ouvrage.
|
Variable |
Valeur de référence |
Rôle dans le modèle |
|
Utilisateurs actifs |
50 |
Détermine le volume de requêtes et l'assiette
de l'abonnement. |
|
Requêtes / utilisateur / jour |
20 |
Avec 250 jours ouvrés, produit 250 000
requêtes annuelles. |
|
Tokens moyens / requête |
1 500 |
Base du calcul de consommation, entrée et
sortie confondues. |
|
Multiplicateur agentique |
× 1 à × 30 |
Facteur le plus sensible : un agent autonome
consomme cinq à trente fois plus qu'un chatbot. |
|
Mode de facturation |
Mixte |
Abonnement par siège, consommation au token,
ou les deux. |
|
CAPEX initial |
30 000 € |
Serveur GPU 15 000 € + infrastructure 5 000 €
+ intégration 10 000 €. |
|
OPEX local annuel |
21 333 € |
Énergie, maintenance, MCO, MLOps, mises à
jour, sauvegarde, gouvernance. |
|
Amortissement |
5 ans |
Convention comptable du chapitre 17. |
Figure 43 — Point d'équilibre entre
infrastructure souveraine et facturation cloud. L'usage agentique déplace
l'équilibre de 15,2 à 4,7 mois : la consommation de tokens, et non la seule
souveraineté, devient le moteur de l'adoption locale.
La fonction la plus
démonstrative : le multiplicateur agentique
Ce curseur est le pivot pédagogique du
module. Toutes choses égales par ailleurs, faire passer un déploiement du
chatbot simple à l'agent autonome multiplie par quinze la consommation de
tokens, porte le coût cloud annuel de 45 083 € à 97 583 €, et ramène le point
d'équilibre de 15,2 à 4,7 mois. C'est la démonstration chiffrée de la thèse
développée dans le Tome 3 : l'économie du token, davantage que la seule
contrainte réglementaire, est le moteur de l'adoption des SLM souverains.
Une honnêteté
méthodologique intégrée
Le module rend trois verdicts distincts, et
non un verdict unique favorable au local. Lorsque le volume est insuffisant, il
indique explicitement que l'API mesurée demeure le choix rationnel et que
l'investissement ne s'amortira jamais. Cette nuance est délibérée : le message
de l'ouvrage est « le bon modèle au bon endroit », jamais « local partout ».
Une réserve s'affiche toutefois lorsque la classification est N3 ou N4 — le
calcul devient alors un argument budgétaire, non un critère de décision.
Le module restitue enfin les cinq indicateurs
FinOps à présenter au COMEX : coût par requête, taux d'utilisation du serveur,
coût par utilisateur actif, taux d'amortissement réalisé et économie cumulée
versus SaaS.
A.4 — Les fonctions du module 3 : l'export
pour le manuscrit
Le troisième module produit la figure
destinée à l'ouvrage, à la charte de la collection : filet bleu souverain,
sceau or, hiérarchie typographique et légende rédigée. Il exporte en trois
formats.
|
Export |
Format |
Destination |
|
Figure 42 — Macro-modèle |
SVG vectoriel |
Insertion dans le manuscrit : qualité
d'impression parfaite à toute échelle. |
|
Figure 42 — Macro-modèle |
PNG 2× (2400 × 1480 px) |
Supports de présentation, blog, réseaux
sociaux. |
|
Figure 43 — Break-even |
SVG vectoriel |
Graphique du point d'équilibre calculé sur
vos propres hypothèses. |
La légende à reporter dans le manuscrit est
fournie avec la figure, prête à être copiée. L'emplacement recommandé est
l'annexe 2, en vis-à-vis du logigramme de choix du modèle (Figure 41) : le
logigramme répond à la question « quel modèle ? », le macro-modèle à la
question « selon quel raisonnement, et à partir de quel seuil ? ».
Partie B — Mode d'emploi
|
EN TRENTE SECONDES Ouvrez le fichier dans n'importe quel
navigateur. Aucune installation, aucune connexion, aucune donnée transmise :
l'outil fonctionne hors ligne. Onglet 1 : répondez aux quatre
questions, lisez le Passeport, copiez la commande Ollama. Onglet 2 : ajustez vos hypothèses,
lisez le point d'équilibre. Onglet 3 : téléchargez la figure. |
B.1 — Ouvrir et diffuser l'outil
Le macro-modèle est un fichier HTML autonome.
Il ne dépend d'aucun serveur, n'écrit rien sur le poste et n'émet aucune
requête vers l'extérieur — à l'exception du chargement des polices de
caractères, qui échoue sans conséquence en environnement isolé. Il est donc
utilisable sur un poste déconnecté, ce qui en fait un outil compatible avec les
contextes N4.
1. Double-cliquez sur le fichier, ou faites-le glisser dans
une fenêtre de navigateur.
2. Pour le diffuser en interne, déposez-le sur un partage
réseau, un Nextcloud ou une page de blog : un simple lien suffit.
3. Pour l'imprimer, utilisez la fonction d'impression du
navigateur : la navigation et les boutons sont automatiquement masqués.
B.2 — Module 1 : obtenir le Passeport de
choix
Étape 1 — Classifier les
données
Sélectionnez le niveau correspondant aux
données que le modèle traitera réellement, et non au niveau moyen de
l'organisation. En cas de doute entre deux niveaux, retenez le plus élevé :
c'est la règle prudentielle du référentiel. Ce choix est le seul qui soit
contraignant — il ferme définitivement la voie cloud pour N3 et N4.
Étape 2 — Déclarer l'usage
Choisissez l'usage principal, pas la totalité
des usages envisagés. Un déploiement qui couvre plusieurs besoins se traite en
plusieurs passages : c'est le principe du portefeuille de cas d'usage du
chapitre 18, et cela produit un Passeport par cas d'usage — donc une
traçabilité par cas d'usage.
Étape 3 — Déclarer le
matériel
Renseignez le matériel effectivement
disponible, non celui que vous envisagez d'acquérir. Le macro-modèle applique
la règle d'or de l'ouvrage : commencer petit, mesurer, puis monter en gamme. Si
la recommandation obtenue vous paraît trop modeste, c'est généralement le signe
qu'un investissement matériel doit précéder le changement de modèle — et non
l'inverse.
Étape 4 — Déclarer le
profil
Le profil déclenche les prescriptions
d'échelle. Le profil « grande entreprise » fait notamment apparaître
l'avertissement de bascule vers vLLM au-delà d'un millier d'utilisateurs
simultanés. Le profil « secteur critique » ré-arbitre le socle vers un modèle
conçu en Europe.
Lire le Passeport
• Le sceau indique le palier de montée en gamme : I pour
les configurations de démarrage, II pour les serveurs GPU, III pour les
clusters.
• Le bouton « Copier » place la commande Ollama exacte dans
le presse-papier, quantification comprise.
• L'encadré de routage rappelle la règle LiteLLM applicable
; reportez-la dans votre configuration de proxy.
• Le bloc « Rattachement au framework » liste les chapitres
et piliers à citer dans le dossier d'audit.
• Le bouton « Précédent » permet de revenir sur une réponse
sans repartir de zéro ; « Recommencer » réinitialise l'ensemble.
B.3 — Module 2 : chiffrer le point
d'équilibre
Le module s'ouvre sur les valeurs de
référence du chapitre 17. Le verdict et le graphique se recalculent à chaque
modification de champ : il n'y a pas de bouton de validation.
Renseigner la volumétrie
4. Utilisateurs actifs : ceux qui utiliseront réellement le
service, pas l'effectif total.
5. Requêtes par utilisateur et par jour : à défaut de
mesure, retenez quinze à vingt-cinq pour un usage bureautique courant.
6. Tokens moyens par requête : mille cinq cents couvre une
question et sa réponse. Un RAG avec contexte documentaire volumineux monte
facilement à quatre ou cinq mille.
7. Multiplicateur agentique : × 1 pour un chatbot, × 5 pour
un assistant outillé, × 15 pour un agent autonome, × 30 pour des agents en
cascade. Faites varier ce curseur en réunion : c'est la démonstration la plus
parlante de l'outil.
Choisir le mode de
facturation
Trois modes sont proposés. « Abonnement »
convient aux offres facturées au siège. « Au token » correspond aux API
mesurées. « Mixte » additionne les deux et reproduit la structure de coûts du
chapitre 17 — c'est le mode par défaut, et le plus fidèle à la réalité des
déploiements observés.
Ajuster les coûts
d'infrastructure
Le CAPEX par défaut agrège serveur GPU,
infrastructure complémentaire et intégration initiale. L'OPEX local agrège
énergie, maintenance matérielle, administration, MLOps, mises à jour,
sauvegarde et gouvernance FinOps. Le bouton « Valeurs du livre » restaure à
tout moment les hypothèses de référence.
Interpréter le verdict
|
Point d'équilibre |
Verdict rendu |
Décision suggérée |
|
Sous 18 mois |
L'inférence locale est économiquement
rationnelle. |
Engager l'investissement : l'équilibre tombe
dans l'horizon d'un exercice budgétaire. |
|
Entre 18 et 36 mois |
Zone de bascule — décision à instruire. |
Arbitrer selon la trajectoire de volumétrie
et le poids accordé à la souveraineté. |
|
Au-delà de 36 mois |
Volume insuffisant pour amortir
l'infrastructure. |
Rester en API, ou mutualiser le serveur entre
plusieurs cas d'usage. |
|
Jamais atteint |
L'API mesurée reste plus économique. |
Ne pas investir — sauf contrainte de
classification N3/N4. |
Un avertissement s'affiche lorsque le module
1 a été renseigné avec une classification N3 ou N4 : le calcul conserve alors
sa valeur budgétaire, mais ne peut plus fonder la décision d'architecture.
B.4 — Module 3 : exporter la figure
8. Ouvrez l'onglet « Figure manuscrit ». La figure s'affiche
à la charte de la collection.
9. « Télécharger le SVG » produit un fichier vectoriel
destiné au manuscrit : insérez-le tel quel dans Word, il reste net à
l'impression quelle que soit la taille.
10. « Télécharger le PNG » produit un fichier tramé en double
résolution, adapté aux présentations et aux publications en ligne.
11. « Télécharger le graphique break-even » exporte la courbe
calculée sur vos propres hypothèses — utile pour illustrer un dossier
d'investissement devant le COMEX ou le conseil d'administration.
12. Reportez la légende fournie sous la figure dans le
manuscrit, en conservant la numérotation de la collection.
B.5 — Points de vigilance
• Les tags de modèles évoluent rapidement. Ne figez jamais
une version en production sans test préalable ; privilégiez ollama pull pour
les mises à jour.
• Les simulations financières sont illustratives. Chaque
organisation doit recalculer son TCO à partir de sa volumétrie réelle, de ses
contraintes réglementaires et de ses perspectives de croissance des usages.
• L'outil documente une décision, il ne la valide pas. Le
Passeport obtenu constitue une pièce du dossier ; la validation relève du
Comité de Souveraineté IA réunissant DSI, DPO et RSSI.
• Aucune analyse d'impact n'est réalisée par l'outil. Un
système classé à haut risque au sens de l'AI Act demeure soumis à AIPD, quelle
que soit la recommandation obtenue.
• Le durcissement n'est pas optionnel. Quel que soit le
modèle retenu, le port 11434 ne doit jamais être exposé : reverse proxy NGINX
et authentification LDAP/SSO restent des prérequis de mise en production.
|
POUR ALLER PLUS LOIN Chapitre 10 — SLM souverains :
Mistral, Phi-4, Llama, Ollama. Comparatif, quantification, routage LiteLLM
N1-N4. Chapitre 4 — Architecture à quatre
couches de la stack UGAIA et clé pivot mlflow_run_id. Chapitre 17 — FinOps : le coût réel de
l'IA souveraine. TCO à trois ans et cinq indicateurs de pilotage. Chapitre 18 — Le ROI de l'IA
générative : du POC au portefeuille continu de cas d'usage. Annexe 2 — Schémas : architecture
souveraine et logigramme de choix du modèle (Figure 41). Annexe B — Framework de gouvernance IA
: les cinq piliers et leurs responsables. Annexe C — Grille d'auto-diagnostic
stratégique : positionnement sur l'échelle UGAIA en une à deux heures. |
Macro-modèle de choix du SLM souverain
Le fil directeur du livre, rendu opérationnel. Quatre questions convergent vers un modèle, sa commande Ollama, son routage LiteLLM N1-N4 et son rattachement au framework des 5 piliers.
Aucun commentaire:
Enregistrer un commentaire