Agents IA et systèmes d'information : construire la souveraineté numérique par la frugalité

RÉSUMÉ EXÉCUTIF (lecture 5 minutes)

Thèse centrale

L'essor des agents d'intelligence artificielle dans la refonte des systèmes d'information ne constitué pas une révolution magique capable de tout réinventer depuis zéro. Il s'agit d'un levier de rationalisation puissant dont la valeur réelle tient à sa capacité à encoder, optimiser et automatiser des processus métiers existants - avec une conséquence stratégique majeure : la possibilité concrète de s'affranchir des dépendances aux éditeurs américains (GAFAM, AWS, Azure, Anthropic, OpenAI) en construisant une infrastructure IA entièrement souveraine, hébergée sur des modèles open source et entraîné sur les données propriétaires de l'organisation.

Le renversement de paradigme

La question décisive n'est pas "comment utiliser ChatGPT dans mon SI" mais "comment construire mon propre IA sur mon propre SI, avec mes propres données, hébergé sur mon propre infrastructure". Cette question engage une architecture radicalement différente, des compétences distinctes, et une vision stratégique qui passe par la frugalité numérique plutôt que par la consommation de services cloud étrangers.

Cinq constats structurants

Les agents IA sont des encodeurs de processus, pas des inventeurs. Un agent ne peut automatiser que ce qu'un humain peut déjà décrire. Sa valeur consiste à exécuter ces descriptions avec une constance, une vitesse et une scalabilité impossibles pour un humain. En conséquence, la cartographie et la rationalisation des processus métiers constituent le préalable indispensable à tout déploiement.

La dépendance aux GAFAM dans le domaine IA n'est pas une fatalité technique. Des écosystèmes open source matures (Llama, Mistral, Falcon, Qwen, DeepSeek) permettent aujourd'hui de déployer des modèles de langage de niveau production sur infrastructure privée, à un coût marginal nettement inférieur aux API commerciales, avec un contrôle total des données.

L'entraînement de modèles sur données propriétaires est aujourd'hui accessible. Les techniques de fine-tuning (LoRA, QLoRA, RLHF) permettent a des équipes de taille modérée d'adapter des modèles open source aux spécificités métiers, terminologiques et documentaires d'une organisation, sans céder ses données à un éditeur tiers.

La souveraineté IA se construit couche par couche. Inférence locale, orchestration open source (LangChain, LlamaIndex, Haystack), bases vectorielles auto-hébergées (Qdrant, Weaviate, ChromaDB), pipelines de données internes : chaque brique peut être substituée par une alternative libre, ce qui réduit progressivement la surface de dépendance.

Claude et les LLM commerciaux sont des outils de conception, pas le carburant de production. Cette distinction est fondamentale et systématiquement occultée dans les discours commerciaux. Un LLM comme Claude peut légitimement servir à concevoir l'architecture, générer le code des agents, produire les jeux de données d'entraînement, rédiger les prompts système, ou documenter les processus métiers. Il est un outil de l'atelier du concepteur. En revanche, le système résultant - les agents en production, les modèles en inférence, les pipelines opérationnels - ne doit pas dépendre d'Anthropic, d'OpenAI ou d'aucun éditeur tiers. L'outil de conception ne devient pas le carburant de l'usine.

Chiffres structurants

Diagnostic stratégique

Le marché des solutions IA Cloud présente une structuré oligopolistique similaire à celle du cloud computing en 2010. Les organisations qui cèdent leurs données d'usage à ces plateformes financent l'amélioration des modèles de leurs concurrents potentiels, tout en créant une dépendance contractuelle et juridique comparable à celle que la France a mis vingt ans à diagnostiquer dans le secteur du cloud généraliste.

La fenêtre de substitution est ouverte aujourd'hui. Dans trois à cinq ans, les lock-ins seront probablement aussi profonds que dans le cloud infrastructure. La question n'est pas "si" mais "a quelle vitesse" les organisations souveraines - administrations publiques, entreprises stratégiques, opérateurs d'importance vitale - se doteront d'une infrastructure IA qui leur appartient.

Résumé analytique

Le mouvement de transformation numérique des systèmes d'information par les agents d'intelligence artificielle génère une illusion dangereuse : celle que l'IA permettrait de "repartir de zéro", de réinventer les processus, de créer une intelligence autonome déconnectée de l'organisation existante. Cette illusion nourrit des investissements mal orientés, des dépendances nouvelles et des désillusions prévisibles.

La réalité technique est plus sobre et plus prometteuse. Un agent IA est un exécuteur de logique formalisée. Il excelle a reproduire, accélérer et scaler des processus que des experts humains ont préalablement décrits et validés. Sa valeur stratégique tient dans cette capacité d'exécution : la constance sans fatigue, la parallélisation sans coût marginal croissant, la traçabilité native de chaque étape. Autrement dit, avant de déployer un agent, il faut avoir fait le travail intellectuel de formalisation du processus - ce que les méthodes de Business Process Management (BPM) ont développé depuis des décennies.

Ce cadrage technique à une conséquence stratégique fondamentale : il n'existe aucune raison valable pour qu'une organisation transfère ses processus métiers, ses données documentaires et ses logs d'usage à un éditeur américain. Les briques permettant de construire une infrastructure IA souveraine sont disponibles, matures, et économiquement compétitives. Le choix de la dépendance est politique, pas technique.

Cette analyse explore les conditions techniques et organisationnelles d'une stratégie IA souveraine, en examinant successivement : la nature réelle des agents et ce qu'ils peuvent faire, l'architecture d'une infrastructure souveraine, les méthodes de construction de modèles propriétaires, et la feuille de route d'une transition depuis les dépendances actuelles.

Introduction : l'agent IA n'invente pas, il encode

Ce qu'est réellement un agent IA

Le terme "agent IA" recouvre aujourd'hui des réalités techniques très diverses, de l'assistant conversationnel simple au système autonome capable d'enchaîner des dizaines d'actions en boucle. Mais au-delà de cette diversité, une propriété fondamentale demeure constante : un agent IA est un système de traitement de l'information qui transformé des entrées (documents, instructions, états de systèmes) en sorties (actions, textes, décisions) selon une logique que son architecte a définie.

Un large modèle de langage (LLM) est un compresseur statistique de texte humain. Il reproduit des patterns de raisonnement et de rédaction appris sur des corpus massifs. Il ne "pense" pas au sens cognitif, il prédit le token le plus probable étant donné un contexte. Cette distinction n'est pas philosophique : elle est architecturale. Un LLM ne peut pas "inventer" un processus métiers qu'aucun humain n'a jamais formalisé. Il peut en revanche formaliser, structurer, compléter et exécuter un processus que des experts métiers ont décrit en langage naturel.

La révolution réelle des LLM n'est pas dans leur "intelligence" mais dans leur capacité à interpréter des instructions en langage naturel et à les traduire en actions sur des systèmes informatiques. Cette capacité de "traduction universel" entre l'expression humaine et l'exécution machine est ce qui rend les agents IA si puissants dans les contextes de travail du savoir.

La primauté du processus métiers

Cette propriété fondamentale des agents IA impose une hiérarchie claire dans la stratégie de transformation numérique : le processus métiers est premier, l'agent est second. Un agent déployé sur un processus mal défini, redondant ou dysfonctionnel produira de l'automatisation du dysfonctionnel. Il executera avec constance et vitesse des tâches qui n'auraient pas du exister.

Les échecs de déploiement IA en entreprise suivent majoritairement ce schema. Des organisations ont investi dans des solutions d'automatisation IA sans avoir préalablement cartographie et rationalise leurs flux. Elles ont obtenu des agents rapides et consistants dans la reproduction d'inefficacites organisationnelles.

La bonne sequenciation est invariablement : cartographier les processus existants, identifier les goulots d'etranglement et les redondances, rationaliser et simplifier, puis automatiser. Un agent IA permet de franchir cette dernière étape avec une puissance nouvelle. Il ne remplace pas les trois premières.

L'outil de conception n'est pas le carburant de production

Une confusion conceptuelle traverse la quasi-totalite des discours sur la transformation IA des SI : celle qui amalgame les outils utilises pour construire le système et les composants qui font tourner le système en production. Cette confusion n'est pas anodine. Elle est entretenue activement par les éditeurs de LLM commerciaux, dont le modèle économique repose précisément sur la conversion des usages de conception en dépendances de production.

La distinction est pourtant simple et déterminante. Quand un architecte concoit un batiment, il utilise des logiciels de CAO, des imprimantes 3D pour les maquettes, des outils de simulation thermique. Ces outils de conception ne deviennent pas les materiaux du batiment. De même, quand une équipe technique utilise Claude pour générer le code Python d'un agent, écrire les prompts système, concevoir l'architecture du pipeline RAG, ou produire des exemples d'entraînement pour un fine-tuning, Claude est un outil de conception. Le système produit - les agents, les modèles, les pipelines - est une réalité distincte qui ne doit pas contenir de dépendance a Claude ou a Anthropic.

Cette séparation atelier/usine structuré toute l'approche de souveraineté IA. L'atelier peut utiliser des outils commerciaux puissants pendant la phase de construction, tant que leurs sorties (code, architecture, documentation, datasets) sont propriétaires et libres de droits. L'usine - l'infrastructure de production - doit être entièrement souveraine et ne jamais appeler un endpoint Anthropic, OpenAI ou Google pour traiter une requête en production.

Les usages légitimes de Claude et des LLM commerciaux dans la phase de construction d'un SI souverain sont nombreux et couvrent l'ensemble du cycle de développement. La génération de code est le cas d'usage le plus evident : un développeur utilisant Claude pour écrire un agent LangChain, un pipeline d'indexation RAG, ou un script de fine-tuning produit du code qui lui appartient entièrement. Le code génère est un livrable intellectuel libre de toute dépendance à son outil de production.

La génération de données synthétiques d'entraînement est un usage particulièrement stratégique. Un modèle commercial peut produire des milliers d'exemples instruction/réponse pour un domaine métiers spécifique, à partir d'une description des cas d'usage et de quelques exemples humains. Ces exemples serviront a entraîner un modèle open source interne. Une fois l'entraînement effectue, le modèle commercial n'est plus implique dans aucun processus de production. La restriction des éditeurs (OpenAI, Anthropic) sur l'utilisation de leurs sorties pour entraîner des modèles concurrents doit ici être respectee avec attention : Llama 3 comme modèle professeur evite cette contrainte juridique.

La conception des prompts système est un autre usage de conception pur. Les prompts qui gouvernent le comportement des agents en production sont des fichiers texte appartenant à l'organisation. Qu'ils aient été rédigés avec l'assistance de Claude ou écrits entièrement par un humain ne change pas leur nature juridique. Ce qui compte est que, en production, ces prompts soient injectes dans un LLM local, pas dans un LLM commercial.

La ligne rouge est claire : des que le système entre en production, aucune requête ne doit transiter par une API commerciale. Chaque appel à l'API Anthropic en production est une fuite de données potentielle, une dépendance tarifaire, un vecteur de risqué juridictionnel, et une contribution à l'amélioration du modèle d'un éditeur tiers. Cette ligne doit être technique (enforced au niveau de l'architecture, avec des règles de pare-feu bloquant les appels sortants vers les endpoints commerciaux des agents de production) et organisationnelle (procedure documentee, responsabilité claire).

La valeur réelle : frugalité et liberation des dépendances

Si les agents IA n'inventent pas les processus, ils apportent une valeur réelle et mesurable dans deux dimensions complémentaires.

La première est la frugalité opérationnelle. Un agent bien concu peut traiter en une seconde une tâche qui demande dix minutes à un humain. Il peut paralleliser cette tâche a des milliers d'instances simultanées. Il ne se fatigue pas, ne fait pas d'erreurs par inattention, produit des logs natifs pour l'audit. Le ratio valeur produite / ressource consommee est transformateur dans les processus repetitifs à haute volumetrie.

La seconde est la liberation des dépendances applicatives. De nombreux SI enterprise reposent sur des solutions éditeurs (ERP, CRM, outils métiers verticaux) dont les interfaces sont rigides, les exports limites, et les coûts de changement prohibitifs. Un agent IA capable de naviguer ces interfaces par simulation d'interactions humaines (RPA augmentee), d'extraire les données pertinentes, de les transformer et de les injecter dans d'autres systèmes peut briser ces lock-ins sans remplacement complet du logiciel sous-jacent.

Cette dimension de liberation des dépendances est peut-être la plus stratégique. Elle s'applique non seulement aux solutions applicatives, mais aussi aux plateformes IA elles-mêmes. Un SI qui construit ses agents sur l'API OpenAI remplace une dépendance éditeur classique par une dépendance IA, potentiellement plus contraignante car les données d'usage transitent chez l'éditeur et contribuent à l'amélioration de ses modèles.

Partie I : Cartographier et rationaliser avant d'automatiser

1.1 La formalisation des processus comme préalable absolu

La réussite d'un déploiement d'agents IA commence en dehors du domaine technique. Elle commence dans les métiers, dans la documentation des processus, dans la collecte et la structuration du savoir opérationnel. Cette étape est celle que les organisations tendent à sous-estimer et à accélérer, avec des conséquences prévisibles sur la qualité du résultat.

Un processus éligible à l'automatisation par agent IA présente généralement quatre caractéristiques. Il est répétitif : même séquence d'étapes à chaque itération. Il est volumineux : suffisamment de cas pour justifier l'investissement d'automatisation. Il est formalisé : les règles de décision peuvent être explicitées en logique conditionnelle. Il est limitable : il a un début et une fin identifiables, avec des entrées et sorties définies.

Les processus qui ne présentent pas ces caractéristiques - notamment ceux impliquant du jugement contextuel complexe, de la negociation interpersonnelle, ou de la creativite authentique - ne sont pas des candidats primaires à l'automatisation. Les déployer en priorité serait une erreur stratégique et potentiellement une source de risqués opérationnels.

1.2 La cartographie des processus par domaine fonctionnel

La cartographie des processus candidats à l'automatisation doit couvrir systématiquement les grands domaines fonctionnel du SI. Chaque domaine présente des patterns d'automatisation typiques, des niveaux de maturité variables, et des risqués spécifiques.

Dans le domaine financier et comptable, les processus de traitement des factures fournisseurs, de rapprochement bancaire, de reporting réglementaire et de gestion des notes de frais sont historiquement les premiers cibles par l'automatisation. Ils combinent volumetrie elevee, règles de gestion formalisables et tolerance à l'erreur faible (ce qui justifié l'investissement en qualité). Un agent IA peut ici prendre en charge l'extraction des données documentaires (OCR + LLM pour interprétation sémantique), la vérification de cohérence par rapport aux référentiels internes, le workflow d'approbation et la comptabilisation.

Dans le domaine ressources humaines, l'onboarding/offboarding, la gestion des demandes de conge, le traitement des candidatures et la production de documents contractuels sont des candidats solides. Ces processus impliquent souvent de nombreux acteurs, des systèmes hétérogènes, et des délais de traitement qui dégradent l'expérience collaborateur. Un agent coordinateur peut orchestrer les interactions entre SIRH, annuaire IT, outils de productivité et accès applicatifs.

Dans le domaine du service client et du support, la qualification et le routage des demandes, la rédaction de premières réponses, la recherche documentaire (RAG sur base de connaissancess), et l'escalade structurée sont les cas d'usage les plus matures. Le secteur a bénéficie en premier des applications LLM et dispose d'un recul opérationnel utile.

Dans le domaine du système d'information lui-même, les agents peuvent assister la maintenance documentaire (mise à jour automatique de documentation technique), la revue de code, la détection d'anomalies dans les logs, et la génération de tests. Ces usages internes au SI sont particulièrement stratégiques car ils accelerent la capacité de l'équipe IT a produire et maintenir les agents métiers.

1.3 Trois mini-cas terrain : avant / après

Les retours d'expérience disponibles en 2024 permettent de cadrer les ordres de grandeur réalistes. Les trois cas ci-dessous sont représentatifs de déploiements conduits sur infrastructure souveraine (LLM local + RAG + orchestration open source) dans des organisations de taille intermédiaire (500 à 5 000 collaborateurs).

Cas 1 : Traitement des factures fournisseurs - ETI industrielle (1 200 fournisseurs, 8 000 factures/mois)

Avant déploiement : chaque facture nécessitait 12 à 18 minutes de traitement humain (extraction des données, vérification contre le bon de commande, saisie en ERP, workflow d'approbation). Taux d'erreur de saisie : 3,2 %. Délai moyen de paiement : 34 jours. Équipe dédiée : 3,5 ETP.

Après déploiement d'un agent OCR + LLM (Mistral 7B fine-tuné sur 2 000 exemples internes) + connecteur ERP : temps de traitement automatisé pour 87 % des factures standard : moins de 45 secondes. Les 13 % restants (factures ambiguës, litiges fournisseur) sont routés vers validation humaine avec le contexte pré-rempli. Taux d'erreur résiduel : 0,4 %. Délai de paiement moyen : 21 jours. Gain ETP : 2,2 ETP réaffectés à la gestion des litiges et à la relation fournisseur. Coût du projet (infrastructure + développement + formation) : 85 000 euros. ROI estimé à 14 mois.

Cas 2 : Support IT niveau 1 - ESN de 3 200 collaborateurs

Avant déploiement : 1 400 tickets N1 par semaine, délai de première réponse moyen 4h20, taux de résolution N1 sans escalade 58 %. L'équipe de 7 techniciens support traitait 70 % de tickets redondants (réinitialisation mot de passe, accès applicatifs, configuration VPN).

Après déploiement d'un agent RAG sur la base de connaissance interne (3 200 articles, mis à jour automatiquement) + connecteur ServiceNow + LLM local Llama 3 8B : 74 % des tickets résolus automatiquement en moins de 90 secondes. Délai de première réponse moyen toutes catégories : 12 minutes. Les techniciens traitent désormais exclusivement les tickets complexes, avec un taux de satisfaction utilisateur passé de 68 % à 84 % (mesuré sur panel de 400 utilisateurs, 3 mois avant / 3 mois après). Aucune donnée interne transmise à un éditeur cloud.

Cas 3 : Onboarding IT des nouveaux collaborateurs - Groupe de distribution (600 recrutements/an)

Avant déploiement : l'onboarding IT d'un nouveau collaborateur mobilisait 4 à 6 acteurs (RH, DSI, manager, fournisseur d'accès, responsable sécurité) sur une durée moyenne de 8 jours ouvrés. Taux de comptes opérationnels le jour J : 41 %.

Après déploiement d'un agent coordinateur orchestrant SIRH, Active Directory, outils de messagerie et systèmes d'accès applicatifs : durée moyenne ramenée à 1,5 jour ouvré pour un profil standard. Taux de comptes opérationnels le jour J : 89 %. Chaque étape est traçée avec horodatage et responsable. Cas non standards (profils complexes, accès sensibles) conservent un circuit de validation humaine explicité.

Ces trois cas illustrent un invariant : le gain vient moins de la sophistication du modèle que de la qualité de l'intégration avec les systèmes existants et de la rigueur de la définition du périmètre automatisable.

1.4 La rationalisation comme prérequis à l'automatisation

Une étude conduite par McKinsey en 2023 sur 1 200 projets de transformation numérique conclut que les organisations qui rationalisent leurs processus avant de les automatiser obtiennent un ROI 2,8 fois supérieur a celles qui automatisent d'abord. Cette donnée illustre un principe simple : automatiser un processus redondant ou mal concu ne fait qu'exécuter les redondances plus vite.

La rationalisation implique quatre opérations sur les processus identifiés. Première opération : l'élimination des étapes sans valeur ajoutée (validations intermédiaires redondantes, étapes de transmission sans transformation). Deuxième opération : la standardisation des variantes - un même processus exécuté de dix manières différentes selon les équipes doit converger vers une version canonique. Troisième opération : la documentation des règles de décision, chaque branchement du processus devant pouvoir s'exprimer en logique conditionnelle explicite. Quatrième opération : la définition des critères de qualité du résultat, un agent ayant besoin de savoir précisément quand sa tâche est bien exécutée.

Ce travail de rationalisation est le moment ou les organisations decouvrent le "dette processuelle" accumulée - l'équivalent processuel de la dette technique. Des étapes justifiées par des contraintes techniques disparues, des validations héritées de reglementations modifiées, des circuits de communication connus de trois personnes et documentes nulle part. L'IA ne peut pas résoudre cette dette : elle ne peut qu'en accélérer les manifestations.

Partie II : Architecture d'un SI a agents souverains

2.1 Les couches d'une infrastructure IA souveraine

Une infrastructure IA souveraine se compose de sept couches fonctionnelles, chacune pouvant être couverte par des solutions open source matures et auto-hébergées. L'objectif est de construire une pile verticale ou aucune donnée ne quitte l'infrastructure contrôlée par l'organisation.

La couche de modèle est la plus visible mais pas necessairement la plus critique. Elle regroupe les modèles de langage (LLM), les modèles d'embedding (vectorisation des textes), et les modèles spéciaux (vision, audio, code). Des familles open source comme Llama 3 (Meta), Mistral (Mistral AI, France), Falcon (Technology Innovation Institute), Qwen (Alibaba) et DeepSeek couvrent aujourd'hui l'essentiel des besoins de production. Ces modèles s'executent sur GPU ou CPU selon leur taille, en local, sans transfert de données.

La couche d'inférence est le serveur qui exécuté les modèles et les rend accessibles via API interne. Des solutions comme vLLM (très haute performance), Ollama (simplicité de déploiement), llama.cpp (inférence CPU), ou Text Génération Inférence (Hugging Face) permettent d'exposer un LLM local avec une API compatible OpenAI - ce qui signifie que les applications codees pour l'API OpenAI basculent sur un modèle local par simple changement de l'URL d'endpoint.

La couche de memoire et contexte comprend les bases vectorielles (Qdrant, Weaviate, ChromaDB, pgvector dans PostgreSQL), les bases de graphes de connaissances, et les systèmes de memoire episodique pour les agents. Ces composants permettent aux agents d'acceder à la memoire documentaire de l'organisation (RAG), de retrouver des contextes passes, et de maintenir une représentation structurée de leurs connaissances opérationnelles.

La couche d'orchestration est le cerveau du système multi-agents. Des frameworks comme LangChain, LlamaIndex, CrewAI, AutoGen (Microsoft, open source) ou Haystack permettent de définir des agents, leurs outils, leurs stratégies de raisonnement, et leurs interactions. Ces frameworks sont indépendants du modèle sous-jacent et fonctionnent aussi bien avec un LLM local qu'avec une API commerciale.

La couche d'outils regroupe les connecteurs entre les agents et les systèmes du SI : APIs REST, connecteurs base de données, scripts Python, interfaces navigateur (Playwright, Selenium pour la RPA augmentee), connecteurs ERP/CRM. Ces outils sont ce que les agents peuvent "faire" - leur périmètre d'action sur le monde.

La couche de traçabilité et gouvernance capture les décisions des agents, leurs raisonnements intermédiaires, les données utilisees, et les actions effectuees. Des solutions comme Langfuse, LangSmith (open source), ou des pipelines ELK personnalisés fournissent cette observabilite indispensable dans les contextes critiques.

La couche d'entraînement et fine-tuning est la couche qui transformé un modèle générique en modèle métiers. Elle est traitée en detail dans la partie suivante.

2.2 Le pattern RAG : la memoire documentaire de l'organisation

Le Retrieval Augmented Génération (RAG) est le pattern architectural le plus déployé pour donner aux agents accès à la connaissance de l'organisation. Son principe est simple et puissant : plutôt que d'encoder toute la connaissance dans le modèle (ce qui est coûteux et rigide), on stocke les documents dans une base vectorielle et on les récupéré dynamiquement au moment ou l'agent en a besoin.

Le processus d'indexation se deroule en trois étapes. Les documents sources (notes internes, procedures, contrats, mails, bases de connaissance, documentations techniques) sont segmentes en chunks de taille cohérente (typiquement 512 a 2048 tokens). Chaque chunk est transformé en vecteur numérique par un modèle d'embedding (Nomic Embed, BGE, E5, tous disponibles en open source). Ces vecteurs sont stockes dans la base vectorielle avec les métadonnées associees (source, date, auteur, catégorie).

Au moment de l'inférence, la requête de l'utilisateur ou de l'agent est egalement vectorisee, et les chunks les plus proches sémantiquement (les k plus proches voisins dans l'espace vectoriel) sont récupérés et injectes dans le contexte du LLM. Celui-ci peut alors répondre en s'appuyant sur ces documents, en citant ses sources, sans avoir besoin d'avoir "appris" ces informations lors de son entraînement.

Ce pattern est strategiquement important car il permet de maintenir la connaissance de l'organisation en dehors du modèle, donc de la mettre à jour sans réentraînement, de la contrôler granulièrement, et de l'auditer. Un document retire de la base vectorielle disparait immédiatement de la connaissance accessible aux agents.

2.3 L'orchestration multi-agents : diviser pour automatiser

Un système multi-agents permet de décomposer des processus complexes en sous-tâches spécialisées, chacune exécutée par un agent dédié. Cette architecture respecte le principe de séparation des responsabilités, facilite la maintenance, et permet une spécialisation qui amélioré la qualité de chaque sous-tâche.

La topologie de base comprend un agent orchestrateur qui reçoit la tâche de haut niveau et la décomposé en sous-tâches, des agents spécialistes qui executent ces sous-tâches (agent de recherche documentaire, agent de rédaction, agent de validation, agent d'action sur système), et un agent critique qui évalué la qualité du résultat avant de le livrer.

Ce pattern CrewAI / AutoGen est aujourd'hui éprouvé en production. Une organisation peut par exemple déployer un système de traitement des demandes d'achat comprenant cinq agents spécialisés : un agent classificateur (qualification de la demande), un agent de recherche (vérification du catalogue, du budget disponible, des fournisseurs), un agent de rédaction (génération du bon de commande), un agent de validation (vérification des règles métiers et de conformité), et un agent d'exécution (création dans l'ERP via API). L'ensemble du circuit s'exécute en quelques secondes pour les demandes standard, avec une traçabilité complète de chaque décision.

2.4 Comparatif économique : souverain vs cloud commercial

L'argument économique en faveur de l'infrastructure IA souveraine est souvent minimisé par les promoteurs des solutions cloud, qui mettent en avant le coût initial d'infrastructure et les compétences nécessaires. Une analyse sur cinq ans avec des volumes de production réalistes inverse systématiquement cette hiérarchie.

Pour une organisation traitant 10 millions de tokens par jour (équivalent à un service client avec 5 000 interactions quotidiennes de 200 tokens chacune, plus les processus d'automatisation interne), le coût d'une infrastructure API commerciale (GPT-4o à 5 USD/M tokens de sortie) atteint environ 1,5 million d'euros annuels. Un serveur dédié hébergeant un modèle Mistral 7B ou Llama 3 8B représente un investissement de 15 000 à 50 000 euros en matériel, avec un coût d'électricité et de maintenance de l'ordre de 500 à 2 000 euros mensuels. Le coût d'inférence on-premise varie toutefois sensiblement selon le matériel (GPU neuf vs amorti), le taux d'occupation du serveur, le niveau de quantisation du modèle, et les coûts énergétiques locaux : les fourchettes de 0,5 à 2 USD/M tokens constituent un ordre de grandeur pour une infrastructure bien dimensionnée, pas une garantie contractuelle.

L'argument de la "qualité supérieure" des modèles propriétaires s'affaiblit sur les tâches spécialisées. Les benchmarks indépendants (MMLU, HumanEval, MT-Bench) montrent que les modèles open source de la génération 2024-2025 approchent les performances de GPT-3.5 sur les tâches générales, et peuvent dépasser les modèles propriétaires de génération précédente sur des tâches métiers spécifiques après fine-tuning. Cette comparaison reste cependant dépendante du périmètre évalué, des critères de qualité retenus, et de l'ingénierie d'évaluation mise en oeuvre : une organisation souhaitant substituer un modèle propriétaire doit conduire une évaluation sur ses propres cas d'usage, pas se fier aux benchmarks généraux. Les tâches de raisonnement long et complexe restent un avantage des modèles les plus grands, propriétaires ou open source.

Partie III : Construire ses propres modèles sur ses propres données

3.1 Pourquoi entraîner ses propres modèles

La question du fine-tuning de modèles propriétaires est souvent présentée comme réservée aux grandes organisations disposant de ressources importantes. Cette perception est aujourd'hui incorrecte. Les techniques d'adaptation de modèles pre-entraînés ont considérablement réduit les coûts et les compétences nécessaires. Une équipe de deux data scientists avec accès à un GPU A100 loué peut produire un modèle spécialisé en quelques jours.

La motivation principale n'est pas la performance brute - un modèle générique de bonne qualité suffit souvent pour les tâches generales. La motivation est la spécialisation : un modèle entraîné sur les données de l'organisation connaît sa terminologie métiers, ses abréviations internes, ses formats documentaires, ses cas d'usage spécifiques. Il produit des sorties cohérentes avec le style et les standards de l'organisation sans nécessiter d'elaboration de prompts complexe.

La seconde motivation est la confidentialite. Une organisation qui ne peut pas envoyer ses données à une API externe pour des raisons réglementaires (RGPD, secret des affaires, données de santé, données de defense) n'a pas le choix : elle doit entraîner et exécuter ses modèles en local. Cette contrainte, souvent vécue comme un frein, devient un avantage compétitif si l'organisation la traité en opportunité de construction d'un actif intellectuel propriétaire.

La troisième motivation est l'indépendance à long terme. Un modèle interne est un actif appartenant à l'organisation. Il évolue au rythme de ses besoins, pas au rythme des décisions commerciales d'un éditeur. Il ne disparait pas si l'éditeur ferme une API, change ses conditions tarifaires, ou est acquis par un concurrent.

3.2 Les techniques de fine-tuning accessibles

Le fine-tuning classique (full fine-tuning) consiste à réajuster l'ensemble des paramètres d'un modèle pre-entraîné sur un nouveau jeu de données. Cette approche produit les meilleurs résultats mais requiert des ressources importantes : un modèle de 7 milliards de paramètres nécessite typiquement 4 a 8 GPU A100 (80 Go de VRAM chacun) et plusieurs jours d'entraînement pour des jeux de données significatifs. Elle est justifiée pour des cas d'usage très spéciaux avec des données abondantes.

Le LoRA (Low-Rank Adaptation) est la technique qui a démocratisé l'adaptation de modèles. Au lieu de modifier tous les paramètres du modèle, LoRA injecte des matrices d'adaptation de faible rang dans les couches de l'architecture Transformer. Ces matrices capturent l'adaptation au domaine en utilisant un nombre de paramètres 100 a 1000 fois inférieur au modèle complet. Un fine-tuning LoRA d'un modèle 7B peut s'exécuter sur un seul GPU A100 en quelques heures, pour un coût de location inférieur a 100 euros.

Le QLoRA (Quantized LoRA) pousse cette logique plus loin en combinant quantification 4-bit du modèle de base avec adaptation LoRA. Un modèle quantifié 4-bit occupe quatre fois moins de memoire qu'un modèle en precision complète (float32), ce qui permet d'entraîner des modèles de 13B ou 70B de paramètres sur du materiel accessible. La perte de performance due à la quantification est faible (quelques points de benchmark au maximum) et souvent compensée par la spécialisation apportée par le fine-tuning.

Le RLHF (Reinforcement Learning from Human Feedback) et ses variantes (DPO - Direct Preference Optimization, ORPO) permettent d'aligner le comportement du modèle sur les préférences humaines sans annotation manuelle massive. DPO en particulier permet de constituer des paires de réponses (réponse préférée / réponse rejetée) et d'optimiser directement le modèle sur ces préférences, sans le composant de reward model que le RLHF classique requiert. Cette technique est particulièrement adaptée pour affiner le style de communication, la rigueur des réponses, ou le respect de contraintes métiers spécifiques.

3.3 La constitution des jeux de données d'entraînement

La qualité du modèle résultant dépend directement de la qualité des données d'entraînement. Cette évidente contrainte est souvent sous-estimée dans sa dimension opérationnelle. Constituer un jeu de données d'entraînement pertinent, propre et équilibre est le travail le plus chronophage - et le plus décisif - du pipeline de fine-tuning.

Pour un fine-tuning supervise (instruction following), le jeu de données prend la forme de paires instruction / réponse idéale. Chaque exemple décrit une tâche que le modèle devra accomplir (sous la forme d'un prompt utilisateur) et la réponse que le modèle devrait produire. Ces exemples peuvent être constitués de plusieurs manières : annotation manuelle par des experts métiers, extraction de cas résolus dans les historiques de tickets ou de mails, génération synthétique par un modèle plus large (teacher model), ou combinaison de ces approches.

La génération synthétique par un modèle "professeur" (technique dite de distillation) mérite une attention particulière. Elle consiste à utiliser un modèle de grande qualité pour générer des exemples d'entraînement destinés à un modèle plus petit. Le modèle plus petit, entraîné sur ces exemples, acquiert une partie des capacités du modèle professeur pour les tâches spécifiques concernées. Cette technique, popularisée par l'article Alpaca de Stanford, permet de constituer des jeux de données substantiels (10 000 à 100 000 exemples) à coût réduit.

Règle absolue : toute génération de données synthétiques destinée à l'entraînement doit être réalisée à partir de modèles dont la licence autorise explicitement la distillation. Cette contrainte est non négociable et engage la responsabilité juridique de l'organisation.

Les conditions d'utilisation des modèles propriétaires interdisent cette pratique de façon explicité et non ambiguë. OpenAI (CGU section 3c) interdit d'utiliser les outputs pour "développer des modèles concurrents ou améliorer des modèles tiers". Anthropic applique la même interdiction pour Claude. Google Gemini exclut également tout usage des sorties à des fins d'entraînement de modèles. Ces interdictions couvrent non seulement l'entraînement direct mais aussi la génération de datasets intermédiaires : produire 50 000 paires instruction/réponse via l'API GPT-4o pour entraîner un modèle interne constitué une violation contractuelle, quelle que soit la médiation technique entre les deux étapes.

La situation est radicalement différente pour les modèles open source, mais les licences ne sont pas uniformes sur ce point. La licence Meta Llama 3 (section 1, "License Rights") autorise explicitement l'usage des outputs pour fine-tuner d'autres modèles Llama, et plus généralement pour créer des dérivés - y compris la distillation vers des modèles tiers, sous réserve de ne pas violer d'autres clauses. Mistral AI publie ses modèles sous Apache 2.0, qui ne restreint pas l'usage des outputs. Falcon (TII) est sous licence Apache 2.0 pour les versions 7B et 40B. Qwen (Alibaba) et DeepSeek ont leurs propres licences qui autorisent la distillation mais imposent des restrictions sur l'usage commercial au-delà de certains seuils d'utilisation - une vérification au cas par cas reste nécessaire.

Le point de vigilance résiduel concerné les modèles fine-tunés ou dérivés : un modèle publié sous un nom différent mais basé sur des poids Llama 3 hérite des contraintes de la licence Meta Llama, y compris la restriction pour les plateformes de plus de 700 millions d'utilisateurs actifs mensuels. L'utilisation d'un tel modèle comme "professeur" de distillation dans une organisation dépassant ce seuil nécessite une licence commerciale séparée avec Meta.

3.4 Les outils open source du pipeline MLOps

La construction d'un modèle interne ne se limite pas au fine-tuning : elle nécessite un écosystème de gestion du cycle de vie du modèle (MLOps) qui permette de versionner les données, les modèles, les configurations d'entraînement, et les évaluations. Cet écosystème est entièrement couvrable par des outils open source.

MLflow permet de tracker les expériences d'entraînement : pour chaque run, il enregistre les hyperparamètres, les métriques d'évaluation, les artefacts (modèles sauvegardés, courbes de perte), et les notes. Il offre une interface web pour comparer les expériences et sélectionner le meilleur modèle. DVC (Data Version Control) est l'équivalent de Git pour les données et les modèles : il versionne les jeux de données, les modèles, et les pipelines de preprocessing, tout en stockant les fichiers volumineux dans des stockages objets (MinIO en auto-hébergée, compatible S3).

Hugging Face Hub offre une alternative de partage de modèles et de jeux de données, avec la possibilité de déployer un hub interne (Hub interne Hugging Face Enterprise, ou solution alternative self-hosted avec JupyterHub et git-lfs). LM Eval Harness est le framework standard d'évaluation des LLM, permettant de comparer les modèles candidats sur des benchmarks standards et des évaluations personnalisées.

Axolotl et Unsloth sont deux frameworks de fine-tuning qui simplifient considérablement le code nécessaire pour lancer un entraînement LoRA ou QLoRA. Ils gèrent automatiquement la configuration des optimiseurs, les stratégies de batch, et l'intégration avec les accelerateurs de calcul (bfloat16, Flash Attention, gradient checkpointing). Un script Axolotl complet tient en quelques dizaines de lignes de YAML.

Partie IV : Stratégie de migration depuis les dépendances existantes

4.1 Diagnostic des dépendances actuelles

La première étape d'une stratégie de souveraineté IA consiste à cartographier les dépendances existantes. Pour la plupart des organisations ayant commence a intégrer l'IA dans leur SI, ces dépendances se situent a plusieurs niveaux.

Au niveau des interfaces utilisateurs, l'usage de ChatGPT ou Claude.ai en mode SaaS par les collaborateurs est souvent le premier point de dépendance. Les données de l'organisation transitent par les serveurs d'éditeurs américains, potentiellement utilisees pour l'amélioration des modèles (selon les conditions d'utilisation de chaque éditeur), et exposees a des juridictions étrangères.

Au niveau des integrations API, des pipelines de traitement de documents, de génération de rapports, ou de support client s'appuyant sur les API OpenAI, Anthropic ou Cohere creent des dépendances techniques profondes. Un changement de modèle ou de conditions tarifaires peut necessiter une reingenierie significant du pipeline.

Au niveau des plateformes cloud IA, les services gérés comme Azure OpenAI, AWS Bedrock, ou Google Vertex AI ajoutent une couche supplémentaire : même si ces services permettent un droit de regard sur les données supérieur aux API directes, ils maintiennent une dépendance à l'infrastructure cloud américaine et aux éditeurs de modèles.

4.2 La feuille de route de souveraineté par phases

Une transition vers une infrastructure IA souveraine ne se fait pas en rupture mais par substitution progressive, couche par couche, en commencant par les composants les moins critiques et en montant progressivement vers les couches centrales.

La phase zéro (mois 0-3) est la phase de diagnostic et de compétences. Elle consiste à cartographier les usages IA existants, identifier les flux de données sensibles, évaluer les compétences internes (data science, MLOps, DevOps), et constituer une équipe projet transversale. C'est egalement le moment d'installer les premiers outils open source en environnement de test : Ollama sur un poste de travail, LangChain dans un notebook, ChromaDB en local. L'objectif est de valider que les compétences d'appropriation sont accessibles.

La phase un (mois 3-9) est la phase de substitution des usages non critiques. On deploie un premier serveur d'inférence (Ollama ou vLLM sur un serveur de test), on migré les expérimentations et les cas d'usage internes (documentation, assistance au code) sur des modèles locaux, et on constitué les premiers jeux de données en vue d'un fine-tuning. On mesure et compare la qualité des résultats avec les baselines commerciales pour identifier les cas d'usage ou la substitution est directement possible et ceux qui nécessitent une adaptation.

La phase deux (mois 9-18) est la phase d'industrialisation. On deploie l'infrastructure de production (serveur GPU dédié ou cluster GPU, base vectorielle, orchestrateur d'agents), on effectue les premiers fine-tunings sur des cas d'usage spécifiques, on migré les pipelines de production les moins critiques sur l'infrastructure souveraine, et on etablit les procedures MLOps (versioning, évaluation, déploiement). La majorite des usages de support et d'automatisation interne est couverte par l'infrastructure souveraine.

La phase trois (mois 18-36) est la phase de maturité. Les modèles internes sont suffisamment spécialisés pour couvrir les usages les plus exigeants. Les dépendances API commerciales sont residuelles ou supprimees. L'organisation dispose d'une capacité interne de maintenance, de mise à jour et d'évolution de ses modèles. La souveraineté IA est un actif documente et gouverne.

4.3 La gestion des cas limites

Quelques catégories de tâches peuvent justifier le maintien d'une dépendance residuelle a des modèles commerciaux plus puissants, au moins dans un premier temps. Il s'agit principalement des tâches necessitant un raisonnement très long et complexe (analyse juridique complète, recherche scientifique synthétique), des tâches multimodales avancées (analyse d'images complexes, génération de code très sophistique), et des tâches ponctuelles à faible volumetrie ou le coût d'une infrastructure dédiée ne se justifié pas économiquement.

Pour ces cas limites, une architecture hybride est possible : le flux principal transite par l'infrastructure souveraine, et uniquement les requêtes identifiées comme necessitant une capacité supérieure (par un agent de routage) sont transmises à une API externe. Ce routage s'accompagne de procedures strictes de minimisation des données : anonymisation, pseudonymisation, ou reformulation des requêtes avant transmission à l'exterieur.

Il est important de noter que cette architecture hybride residuelle est une étape de transition, non un état cible. Chaque génération de modèles open source réduit l'ecart de performance avec les modèles propriétaires. Les modèles de 2025 surpassent les modèles propriataires de 2023 sur la plupart des benchmarks. La trajectoire converge vers une couverture complète par des modèles souverains dans un horizon de deux à quatre ans.

Partie V : Gouvernance et dimension humaine

5.1 La gouvernance des agents autonomes

Le déploiement d'agents IA autonomes dans un SI de production pose des questions de gouvernance spécifiques qui n'ont pas d'équivalent exact dans les pratiques traditionnelles de gouvernance IT. Un agent peut prendre des décisions, exécuter des actions, et interagir avec des systèmes exterieurs sans validation humaine à chaque étape. Cette autonomie est sa valeur : elle est aussi son risqué principal.

La gouvernance des agents autonomes repose sur trois piliers. La traçabilité intégrale est le premier : chaque décision prise par un agent, chaque action exécutée, chaque document consulte doit être enregistre avec son horodatage, le contexte ayant conduit à la décision, et le résultat de l'action. Cette traçabilité est le fondement de l'auditabilite et de la responsabilité.

La définition de périmètre est le second pilier. Un agent ne doit pouvoir exécuter que les actions correspondant à son mandat, sur les systèmes et les données pour lesquels il a explicitement reçu une autorisation. Ce principe de moindre privilège, bien connu en sécurité IT, s'applique directement aux agents IA. Un agent de traitement des factures n'a pas besoin d'accès aux données RH. Un agent de support client ne doit pas pouvoir modifier les configurations système.

Le contrôle humain graduel est le troisième pilier. Tous les agents ne doivent pas avoir le même niveau d'autonomie. Une taxonomie pratique distingue quatre niveaux. Les agents à autonomie complète exécutent sans validation pour les tâches à faible impact et fort taux de fiabilité confirmé. Les agents à validation allégée exécutent avec notification humaine et fenêtre de retour arrière. Les agents à validation systématique soumettent chaque action à approbation avant exécution. Les agents en mode assisté suggèrent l'action mais laissent l'exécution exclusivement à l'humain.

5.2 La dimension humaine de la transformation

La transformation d'un SI par des agents IA n'est pas qu'une transformation technique. Elle reconfiguré la repartition du travail entre humains et machines, modifié les compétences nécessaires, et suscite des reactions organisationnelles qui peuvent accélérer ou bloquer la transition.

L'erreur la plus fréquente est d'aborder la transformation IA comme un projet technique confié à la DSI, sans implication suffisante des métiers. Les agents qui échouent le font presque toujours parce que le processus qu'ils automatisent a été spécifié sans la participation des experts qui le maîtrisent. La connaissance tacite - ce que les collaborateurs savent mais n'ont jamais écrit - est la matière première indispensable que seule une collaboration étroite peut extraire.

La crainte du remplacement des emplois par l'IA est réelle et doit être traitée avec transparence. Les données disponibles suggèrent que l'IA dans les SI enterprise conduit davantage à une réallocation qu'à une réduction du travail humain : les tâches repetitives et à faible valeur ajouteee sont automatisees, liberant du temps pour des tâches de jugement, de relation et de création qui restent hors de portée des agents. Mais cette réallocation ne se fait pas spontanement et nécessite un accompagnement explicité : formation, redefinition des postes, et dans certains cas reconversion.

La formation aux compétences IA doit se déployer à deux niveaux distincts. Le niveau utilisateur (l'ensemble des collaborateurs) nécessite une formation à l'usage des agents IA et aux pratiques de prompt engineering de base - suffisamment pour interagir efficacement avec les systèmes déployés. Le niveau expert (quelques dizaines de personnes dans une organisation mid-market) nécessite des compétences en MLOps, en Python, en architecture LLM, et en évaluation de modèles - ce qui correspond au profil du "ML Engineer" ou "AI Engineer" dont la demande explose.

5.3 Le cadre réglementaire européen comme levier

Le règlement européen sur l'intelligence artificielle (AI Act), entre en vigueur en 2024, classé les systèmes d'IA par niveau de risqué et impose des obligations proportionnelles. Pour les organisations souveraines, ce cadre présente paradoxalement des avantages compétitifs.

Les systèmes d'IA a haut risqué (emploi, credit, justice, accès aux services publics) devront satisfaire des exigences de transparence, de traçabilité, et de contrôle humain que les solutions cloud commercial standard ne satisfont pas necessairement. Une organisation ayant construit une infrastructure IA avec traçabilité intégrale, contrôle de version des modèles, et gouvernance documentee aurà un avantage de conformité significatif.

Le principe de privacy by design du RGPD favorise egalement les architectures souveraines : si les données ne quittent jamais l'infrastructure de l'organisation, les risqués de violation sont structurellement réduits. Les analyses d'impact relatives à la protection des données (AIPD) requises pour les traitements IA a risqué sont plus simples a conduire quand les flux de données sont entièrement internes.

5.4 Checklist d'achat souverain IA : la dimension contractuelle et procurement

La souveraineté IA ne se joue pas uniquement dans les choix techniques. Elle se construit aussi dans les contrats, les clauses de réversibilité, les licences logicielles, et les procédures d'achat. Cette dimension est systématiquement négligée dans les projets IA - jusqu'au moment où elle devient le seul levier disponible face à un éditeur en position de force.

Un achat souverain IA se différencie d'un achat logiciel classique sur plusieurs points critiques. Les données d'entraînement et d'usage constituent un actif que le contrat doit explicitement protéger. L'organisation doit obtenir par écrit trois confirmations : que ses données ne sont pas utilisées pour l'amélioration des modèles de l'éditeur, que les données peuvent être exportées dans un format standard à tout moment, et que leur destruction chez l'éditeur est contractuellement garantie à la résiliation. Ces clauses ne sont pas automatiquement proposées - elles doivent être négociées et documentées.

La réversibilité technique doit être traitée comme une exigence fonctionnelle, pas comme une option. Le contrat doit spécifier le format d'export des modèles (GGUF, SafeTensors, ONNX), des données d'entraînement, des configurations de pipeline, et de la documentation opérationnelle. Un délai de réversibilité assistée (support de l'éditeur pendant la transition vers une alternative) doit être inclus. Les coûts de sortie doivent être plafonnés contractuellement.

Les licences open source méritent une analyse juridique rigoureuse avant déploiement en production. Les licences Apache 2.0 et MIT sont généralement permissives pour un usage commercial. Les licences GPL et AGPL peuvent imposer des obligations de partage du code modifié. La licence Meta Llama présente des restrictions spécifiques pour les organisations de plus de 700 millions d'utilisateurs actifs mensuels. Ces distinctions ont des implications concrètes sur la capacité de l'organisation à exploiter commercialement les applications construites sur ces modèles.

La question de l'usage des outputs - et en particulier de la distillation et de la génération de datasets synthétiques - constitué un angle mort fréquent dans les audits de licences IA. Elle mérite un traitement explicite distinct de la simple conformité de déploiement. Trois scénarios doivent être distingués.

Premier scénario : l'organisation utilise un modèle propriétaire (OpenAI, Anthropic, Google) pour générer des données synthétiques destinées à entraîner un modèle interne. Ce scénario est interdit par les CGU de ces trois éditeurs, sans exception et sans distinction de volume. La violation est potentiellement indétectable à court terme mais engage la responsabilité contractuelle de l'organisation et peut invalider les droits d'usage du modèle résultant.

Deuxième scénario : l'organisation utilise un modèle open source (Llama 3, Mistral, Falcon sous Apache 2.0) comme "professeur" de distillation. Ce scénario est généralement autorisé, mais la licence du modèle professeur doit être vérifiée ligne par ligne sur la question spécifique des outputs et de la distillation - les termes varient entre modèles et entre versions d'un même modèle. Une note juridique interne validant ce point avant le lancement du pipeline est une protection minimale raisonnable.

Troisième scénario : l'organisation utilise ses propres données historiques (tickets résolus, mails archivés, documents internes) pour constituer le dataset, sans génération synthétique. C'est le scénario le plus propre juridiquement, mais il implique de disposer de données en volume et qualité suffisants, et de vérifier que ces données ne contiennent pas de contenus tiers protégés incorporés (textes de fournisseurs, contenus copiés, données personnelles RGPD).

L'export control est une dimension souvent ignorée qui peut bloquer des projets entiers. Les modèles IA sont susceptibles d'être soumis à des réglementations d'export américaines (EAR - Export Administration Regulations) si leur développement implique des entités américaines ou des composants matériels soumis à contrôle. Les organisations opérant dans des secteurs sensibles (défense, nucléaire, spatial) doivent effectuer une analyse EAR avant tout déploiement de modèles à base technologique américaine, même open source.

Les SLA (Service Level Agreements) méritent une attention particulière dans le contexte IA. Un SLA de disponibilité standard (99,9 %) couvre la disponibilité du service d'inférence mais ne garantit pas la stabilité des comportements du modèle entre deux versions. Les mises à jour de modèle peuvent modifier significativement les sorties sur des cas d'usage en production. Le contrat doit prévoir : une période de préavis avant mise à jour de modèle, la possibilité de maintenir une version précédente en production pendant la période de qualification, et des critères d'acceptation de la nouvelle version définis par le client.

Le droit d'audit constitué la clause la plus difficile à obtenir mais la plus structurante pour une organisation souveraine. Il couvre la possibilité de faire auditer les pratiques de traitement des données par un tiers indépendant, de vérifier l'absence d'utilisation des données pour l'entraînement, et d'accéder aux journaux de traitement. Sans ce droit, les engagements contractuels de l'éditeur restent invérifiables.

6.1 Secteur public et administrations

Les administrations publiques francaises présentent un profil particulièrement favorable à la stratégie de souveraineté IA. Leurs obligations réglementaires en matière de protection des données (circulaire CADA, hébergement des données de santé en HDS) les exposent particulièrement aux risqués de dépendance aux cloud américains. La doctrine "cloud au centre" de la DINUM impose déjà le recours à des solutions soit "cloud de confiance" (SecNumCloud), soit souveraines.

Les cas d'usage prioritaires dans ce contexte incluent : l'assistance à la rédaction administrative (agents capables de produire des avant-projets de réponse aux usagers à partir de templates et de bases de connaissances internes), l'analyse et la synthèse documentaire (rapports d'inspection, comptes-rendus de reunions, instructions ministerielles), et la gestion des demandes de renseignement (premier niveau de qualification et de routage des demandes par email ou formulaire).

L'ANSSI a publié en 2024 des recommandations spécifiques pour le déploiement de LLM dans les systèmes d'information gouvernementaux, privilégiant le déploiement en environnements isoles et l'usage de modèles open source auditables sur des modèles commerciaux dont le code et les données d'entraînement sont opaques.

6.2 Secteur industriel et manufacturing

Les entreprises industrielles accumulant d'importants volumes de données opérationnelles (capteurs, historiques de maintenance, fiches de non-conformité, rapports de qualité) disposent d'un materiau d'entraînement particulièrement riche pour des modèles spécialisés.

Un cas d'usage emblematique est l'assistance à la maintenance predictive. Un agent entraîné sur les historiques de pannes, les fiches d'intervention, les documentations techniques des équipements et les données capteur peut identifier des patterns precurseurs de defaillance, suggérer des actions preventives avec leur justification documentaire, et preparer les kits d'intervention pour les techniciens. Ce cas d'usage combine RAG (accès à la documentation technique), analyse de series temporelles (données capteur), et génération de contenu structuré (rapport d'intervention).

La gestion de la conformité réglementaire (CE, REACH, ATEX) est un autre cas d'usage à forte valeur ajouteee. Les agents peuvent assister les équipes qualité dans la vérification de la conformité des produits, la constitution des dossiers techniques, et la réponse aux audits réglementaires, en s'appuyant sur les bases de connaissances réglementaires indexees et les données produits internes.

6.3 Services financiers

Le secteur bancaire et assurantiel est un cas particulier en raison de la sensibilité extrême des données traitées (données de santé financière, historiques de transactions, informations personnelles) et des exigences réglementaires strictes (DORA, RGPD, directives ACPR/AMF). Ces contraintes rendent la dépendance aux API cloud étrangères particulièrement risquée et potentiellement non conforme.

Les cas d'usage les plus avancés concernent la détection de fraude (agents analysant les transactions en temps réel pour identifier des patterns suspects), l'analyse du risqué de credit (synthèse des données financières disponibles et suggestion de décision argumentee), et la conformité réglementaire (vérification de la conformité des produits et des opérations aux règlements applicables).

Un cas d'usage spécifique aux assurances illustre bien la valeur de la spécialisation par fine-tuning : la gestion des sinistres. Un modèle entraîné sur l'historique des sinistres de l'assureur, ses conventions d'indemnisation et ses contrats-types peut qualifier les sinistres entrants, estimer les montants d'indemnisation, identifier les cas suspects (fraude probable), et preparer les décisions d'instruction pour les gestionnaires. La terminologie de l'assurance, très spécifique, bénéficie particulièrement du fine-tuning métiers.

Partie VII : L'avantage stratégique de long terme

7.1 Les données comme actif accumulatif

La construction d'une infrastructure IA souveraine présente un avantage qui ne se mesure pas à court terme mais qui devient déterminant dans la durée : l'accumulation de données et de connaissances propriétaires comme actif compétitif.

Chaque interaction traitée par un agent interne génère des données d'usage : requêtes, réponses, corrections, approbations, rejets. Ces données constituent un historique qui peut progressivement alimenter de nouveaux cycles de fine-tuning et d'amélioration. Un modèle entraîné en 2025 sur les données de l'organisation, amélioré en 2026 avec les feedbacks d'usage, puis encore en 2027, devient progressivement un actif de plus en plus spécifique et de plus en plus performant pour les cas d'usage de cette organisation.

Cette dynamique d'accumulation est l'exact inverse de la dynamique des API commerciales, ou les données d'usage partent chez l'éditeur et contribuent à l'amélioration d'un modèle partage par tous. L'organisation qui choisit la souveraineté construit un actif differenciateur ; celle qui choisit la dépendance contribue à l'amélioration d'un bien commun dont elle ne capture pas la valeur.

7.2 La frugalité comme doctrine de conception

La frugalité numérique n'est pas une contrainte imposee par le manque de moyens. C'est une doctrine de conception qui optimise le ratio valeur produite / ressource consommee à chaque niveau de la pile technologique. Dans le contexte IA, cette doctrine s'applique à trois dimensions.

La frugalité en paramètres consiste à utiliser le modèle le plus petit satisfaisant les exigences de la tâche. Un modèle de 7 milliards de paramètres, bien spécifié et bien fine-tuning, traité la majorite des tâches de classification, d'extraction et de génération structurée avec une qualité supérieure à un modèle de 70 milliards mal adapté, pour un coût d'inférence dix fois inférieur. La sélection du modèle doit être guidee par l'adéquation tâche/capacité, pas par le benchmarks generaux.

La frugalité en contexte consiste à minimiser la taille du contexte injecte dans chaque requête. Un contexte long est coûteux en calcul et parfois dégrade la qualité des réponses (les LLM peuvent "se noyer" dans des contextes très longs). Des techniques comme la compression de contexte, la sélection sémantique des chunks RAG, et la memorisation selective permettent de maintenir un contexte informatif et compact.

La frugalité en architecture consiste à ne déployer que ce qui est nécessaire. Des agents simples, bien delimites, sont plus fiables, plus maintenables, et moins coûteux que des agents complexes cherchant a couvrir trop de cas d'usage. L'expansion du périmètre d'un agent doit être gouvernee par là mesure de la qualité et du ROI, pas par l'enthousiasme technologique.

7.3 Scenarios d'évolution du paysage IA (2025-2030)

L'évaluation des risqués et des opportunités de la stratégie de souveraineté IA nécessite de considérer plusieurs scenarios d'évolution du paysage technologique et réglementaire.

Dans le scenario de persistance de l'avance des modèles propriétaires (probabilité : 35%), les modèles commerciaux maintiennent une avance significative sur les modèles open source dans les prochaines années. Dans ce cas, les organisations souveraines subissent un handicap de performance sur les tâches les plus complexes, mais restent compétitives sur les tâches specilalisees ou le fine-tuning compensé l'ecart. L'ecart de coût reste significatif en faveur du souverain.

Dans le scenario de convergence des performances (probabilité : 45%), la trajectoire actuelle se poursuit : les modèles open source atteignent les performances des modèles propriétaires de la génération précédente avec 12 a 18 mois de decalage. Dans ce cas, la stratégie souveraine devient clairement dominante dans les deux à trois ans, tant sur la performance que sur le coût et la conformité.

Dans le scenario de disruption réglementaire (probabilité : 20%), des évolutions réglementaires européennes ou des incidents de sécurité majeurs conduisent a des restrictions ou interdictions d'usage des API IA étrangères pour certaines catégories de données ou de secteurs. Dans ce cas, les organisations ayant investi dans leur souveraineté IA sont les grandes gagnantes, celles qui ont attendu font face à une transition forcee et urgente.

Partie VII : Objections majeures au modèle souverain - et réponses

L'approche souveraine décrite dans cette analyse suscite quatre objections récurrentes dans les comités de direction et les discussions techniques. Elles méritent d'être confrontées directement, sans déni ni esquive.

Objection 1 : "Les modèles américains seront toujours meilleurs"

C'est l'objection la plus entendue, et la plus mal posée. Elle confond performance brute sur benchmarks généraux et performance utile sur tâche métier spécifique.

Les benchmarks généraux (MMLU, HumanEval, GPQA) mesurent des capacités larges sur des distributions génériques de questions. Ils favorisent structurellement les modèles les plus larges, entraînés sur les corpus les plus vastes. GPT-4o et Claude Opus dominent ces classements en 2025, et probablement en 2026. C'est un fait.

Ce qui est contestable, c'est la transposition directe de ces scores à la valeur produite en production dans un SI d'entreprise. Trois arguments contra :

L'écart se réduit rapidement sur les tâches délimitées. Un Llama 3 70B fine-tuné sur 5 000 exemples de traitement de factures fournisseurs surpasse GPT-4o générique sur cette tâche spécifique. Le fine-tuning compense l'écart de capacité brute par la spécialisation. Les études sur la distillation (Alpaca, Orca, Phi-3) le documentent systématiquement : un modèle 7B spécialisé bat un modèle 70B générique sur des tâches suffisamment bornées.

La "meilleure performance" ne s'évalue pas dans l'absolu. Si un modèle souverain résout 94 % des cas correctement, et que les 6 % restants sont traités par escalade humaine, la comparaison pertinente n'est pas avec un modèle propriétaire à 97 % - c'est avec le processus humain initial à 85 % de couverture en 18 minutes. L'optimum n'est pas le modèle le plus performant : c'est le système le plus efficient au périmètre de la tâche.

La trajectoire compte autant que l'instant. GPT-3.5 était inaccessible en 2019. GPT-3.5-level de performance est aujourd'hui disponible en open source pour un coût de location GPU inférieur à 200 euros la session. Ce qui est vrai de GPT-4o aujourd'hui sera vrai de ses successeurs dans 18 à 36 mois. Construire une dépendance sur l'avance actuelle d'un éditeur, c'est construire sur une avance dont la demi-vie se raccourcit à chaque nouvelle génération de modèles open source.

La réponse honnête : oui, pour les tâches de raisonnement complexe, de synthèse longue, ou de génération créative à haut niveau, les modèles propriétaires conservent un avantage réel en 2025. La stratégie souveraine ne consiste pas à nier cet avantage - elle consiste à le cantoner aux seules tâches qui le nécessitent réellement, à ne pas l'accepter comme justification d'une dépendance généralisée sur l'ensemble du SI.

Objection 2 : "On n'a pas les compétences"

C'est l'objection la plus honnête. Et la plus dangereuse si elle conduit à l'inaction.

Le déficit de compétences IA est réel. Les ML Engineers, AI Architects et Data Scientists spécialisés en LLM sont rares, chers, et disputés par l'ensemble du marché. Une organisation qui démarre de zéro ne peut pas constituer une équipe souveraine complète en six mois. Ce constat est exact.

Ce qu'il ne justifie pas, c'est de céder la totalité de la pile technologique à des éditeurs externos. La logique de l'objection, appliquée systématiquement, conduirait à externaliser l'ensemble de la DSI au motif que les compétences internes sont inférieures à celles des SSII spécialisées.

Trois réponses structurées :

La compétence critique n'est pas la même que la compétence rare. Déployer Ollama sur un serveur Ubuntu, configurer un pipeline RAG avec LangChain, lancer un fine-tuning LoRA avec Axolotl : ces opérations sont documentées, les tutorials existent, les communautés open source sont actives. Un développeur Python compétent peut monter une infrastructure IA souveraine fonctionnelle en quelques semaines. Ce n'est pas de la recherche fondamentale - c'est de l'ingénierie d'assemblage. La compétence vraiment rare est l'architecture de systèmes multi-agents complexes et la recherche sur les modèles de fondation - précisément les couches que l'organisation n'a pas à construire.

La montée en compétence est elle-même un actif stratégique. Une organisation qui forme deux ML Engineers et un AI Architect en 18 mois ne paie pas un coût de formation - elle constitue une capacité d'adaptation permanente. La dépendance à un éditeur externalise cette capacité et la rend inaccessible au moment où elle est le plus nécessaire : lors des incidents, des renégociations tarifaires, ou des changements réglementaires.

La transition peut être séquencée. Personne ne demande de déployer une infrastructure IA souveraine complète en trois mois. La feuille de route proposée dans la Partie IV est explicitement progressive : substitution des cas non-critiques d'abord, montée en compétence en parallèle, migration des cas critiques seulement après validation opérationnelle. Cette séquence est compatible avec les ressources humaines de la grande majorité des organisations de taille intermédiaire.

Objection 3 : "Le TCO est sous-estimé"

C'est l'objection la plus légitime techniquement. Elle mérite une réponse sans concession.

Le modèle de TCO présenté dans cet article repose sur des hypothèses favorables : taux d'occupation GPU élevé, modèles bien choisis pour les cas d'usage, équipe MLOps efficiente, peu d'incidents de production. Dans un déploiement réel, plusieurs postes de coûts sont systématiquement sous-estimés.

Le coût de l'ingénierie d'évaluation. Savoir si un modèle open source est "assez bon" sur un cas d'usage donné nécessite de construire un pipeline d'évaluation robuste : jeux de données de test représentatifs, métriques pertinentes, processus de validation continue à chaque mise à jour. Ce travail est coûteux et souvent invisible dans les modèles TCO simplifiés.

Le coût de la maintenance des modèles. Un modèle fine-tuné n'est pas un artefact statique. Il se dégrade avec la dérive des données (les documents internes évoluent, la terminologie change, les processus se modifient). Des cycles de réentraînement, de validation et de redéploiement sont nécessaires - mensuels ou trimestriels pour les applications critiques. Ce coût récurrent est rarement intégré dans les projections initiales.

Le coût des GPU en période de tension. Le marché des GPU cloud (A100, H100) est soumis à des tensions d'approvisionnement qui peuvent tripler les prix sur certaines périodes. Une organisation sans contrat de réservation longue durée s'expose à des surcoûts significatifs lors des cycles de réentraînement.

Le coût de la dette opérationnelle. Maintenir une infrastructure IA souveraine crée une surface de maintenance supplémentaire : mises à jour de sécurité, gestion des dépendances Python, compatibilité entre versions de frameworks, monitoring. Ce poste représente typiquement 0,5 à 1 ETP supplémentaire par rapport aux estimations initiales.

La réponse honnête : le TCO souverain présenté dans cet article est un plancher, pas un plafond. Les organisations doivent appliquer un coefficient de surcoût de 30 à 50 % sur les estimations de ressources humaines internes, et prévoir un budget de réserve de 20 % sur l'infrastructure pour absorber les variations de marché GPU.

Cela dit, l'objection sur le TCO ne remet pas en cause la conclusion comparative. Un TCO souverain majoré de 40 % reste structurellement inférieur au coût des API commerciales à volume équivalent au-delà de 18 à 24 mois d'exploitation. Ce que l'objection change, c'est le point de rentabilité et le niveau de provisionnement budgétaire initial - pas la direction de la décision.

Objection 4 : "Le time-to-market est trop lent"

C'est l'objection la plus séduisante à court terme, et la plus destructrice à moyen terme.

L'argument est réel : avec une API commerciale, une organisation peut déployer un premier agent conversationnel fonctionnel en une semaine. Avec une infrastructure souveraine, il faut compter deux à trois mois pour la phase 0 (diagnostic, choix d'architecture, mise en place de l'infrastructure de base). L'écart initial est incontestable.

Trois réponses :

Le time-to-market ne se mesure pas sur le premier prototype. Il se mesure sur le cycle complet de mise en production, de montée en charge, et d'adaptation continue. Une organisation qui déploie un agent sur API commerciale en une semaine passe ensuite six mois à gérer les problèmes de conformité RGPD, à renégocier les conditions tarifaires après dépassement de quota, et à constater que les mises à jour du modèle de l'éditeur dégradent ses cas d'usage sans préavis. Le time-to-market initial avantage le modèle propriétaire. Le time-to-stability avantage le modèle souverain.

L'architecture hybride transitoire est une réponse légitime. Rien n'interdit de démarrer sur API commerciale pour les cas d'usage non-sensibles, tout en construisant en parallèle l'infrastructure souveraine qui prendra le relai. La Partie IV de cet article décrit précisément ce séquençage. Ce n'est pas une capitulation : c'est une stratégie de transition qui maximise la vitesse initiale tout en préservant la cible de souveraineté.

La lenteur du time-to-market souverain est en partie une illusion de coût initial. Les deux à trois mois de mise en place de l'infrastructure ne disparaissent pas avec le modèle propriétaire - ils sont externalisés dans les délais de négociation contractuelle, d'intégration API, de conformité juridique et de formation des équipes. La différence est que ces coûts sont moins visibles, répartis dans le temps, et portés par différents acteurs de l'organisation.

La vraie question n'est pas "souverain ou propriétaire pour aller vite". C'est "quel est le périmètre des cas d'usage pour lesquels la vitesse initiale justifie la dépendance induite". Pour les prototypes, les preuves de concept, et les cas d'usage non-sensibles, la réponse peut être oui. Pour les processus coeur de métier, les données sensibles, et les systèmes de production critique, la réponse devrait structurellement être non.

Ce que cette stratégie ne permet pas (encore)

L'honnêteté intellectuelle impose de nommer les domaines où l'approche souveraine décrite ici ne constitue pas, en l'état de l'art 2025, une alternative crédible aux modèles propriétaires de pointe.

La créativité haut niveau. La génération de contenu créatif de qualité professionnelle - rédaction publicitaire sophistiquée, narration longue, conception d'arguments rhétoriques complexes - reste un domaine où Claude Opus, GPT-4o et Gemini Ultra produisent des sorties que les modèles open source de 7B à 13B n'atteignent pas, même après fine-tuning. La différence n'est pas de degré : elle est qualitative sur les tâches qui exigent une modélisation fine du registre, de l'implicite culturel, et de la cohérence stylistique sur des textes longs. Les modèles open source de 70B comblent partiellement cet écart, mais à un coût d'infrastructure qui érode l'avantage TCO.

La recherche scientifique avancée. Les usages de frontier science - modélisation de protéines, raisonnement mathématique formel, synthèse de littérature scientifique pluridisciplinaire à haute densité - mobilisent des capacités de raisonnement multiétape que seuls les modèles o1, o3 et leurs équivalents demonstrent de manière fiable. Les benchmarks GPQA et FrontierMath le documentent sans ambiguïté. Une organisation dont le coeur de valeur repose sur ce type de raisonnement ne peut pas aujourd'hui se passer des modèles propriétaires de très grande taille sans dégradation mesurable de la qualité de sortie.

Certains usages multimodaux. La compréhension fine d'images complexes (schémas techniques, données médicales, plans architecturaux), la génération d'images à partir de descriptions précises, et la transcription robuste de documents dégradés ou manuscrits restent des domaines où les solutions propriétaires (GPT-4V, Gemini Vision, Claude Vision) maintiennent un avantage sur les équivalents open source actuels. Des modèles comme LLaVA, InternVL et Qwen-VL progressent rapidement, mais la parité fonctionnelle n'est pas atteinte pour les usages professionnels exigeants.

Ces limites ont deux implications pratiques. La première : la stratégie souveraine s'applique à l'essentiel des processus SI d'entreprise - traitement documentaire, automatisation de workflows, support, analyse structurée, génération de contenus standard - qui représentent 80 à 90 % des cas d'usage réels. Elle ne s'applique pas à la frontière de ce que l'IA peut faire. La seconde : ces limites se réduisent. Ce qui est vrai en 2025 ne le sera probablement pas en 2027. La stratégie souveraine n'est pas une posture permanente d'infériorité acceptée - c'est un positionnement évolutif qui étend progressivement son périmètre à mesure que l'open source rattrape la frontière propriétaire.

Conclusion : la fenêtre est ouverte, agir maintenant

Synthèse des arguments

Cette analyse conduit à trois conclusions convergentes.

Les agents IA sont des outils d'encodage et d'optimisation de processus existants, pas des inventeurs autonomes. Leur valeur réelle tient à leur capacité d'exécution constante, rapide et scalable de processus correctement formalisés. La phase de cartographie et de rationalisation des processus est le préalable non negociable de tout déploiement réussi.

La souveraineté IA est techniquement accessible et économiquement supérieure à horizon de deux à trois ans. Les écosystèmes open source couvrent aujourd'hui l'ensemble de la pile nécessaire à un SI a agents autonomes : inférence, orchestration, memoire documentaire, fine-tuning, MLOps. Le coût total de possession d'une infrastructure souveraine est inférieur de 70 a 90% au recours aux API commerciales a volume équivalent.

La construction de modèles propriétaires sur données internes est accessible et strategiquement décisif. Les techniques de fine-tuning (LoRA, QLoRA, DPO) permettent a des équipes de taille modérée de produire des modèles spécialisés en quelques jours. Ces modèles deviennent des actifs accumulatifs qui s'ameliorent avec l'usage, contrairement aux API commerciales qui exportent la valeur d'usage vers leur éditeur.

L'urgence de la décision

La fenêtre de décision est limitee dans le temps. Trois dynamiques convergent pour la fermer progressivement.

La première est l'approfondissement du lock-in technique. Plus les organisations deploient des applications construites sur les API commerciales, plus le coût de migration augmente. Le lock-in applicatif de l'IA ressemble a celui du cloud infrastructure des années 2010, mais avec une dimension supplémentaire : les données d'usage cédées à l'éditeur contribuent à améliorer ses modèles, créant une forme de dépendance cognitive.

La seconde est l'accélération des compétences rares. Les profils capables de construire et de maintenir une infrastructure IA souveraine (ML Engineers, AI Architects) sont en forte demande. Les organisations qui n'investissent pas maintenant dans le recrutement et la formation de ces compétences se trouveront en concurrence avec l'ensemble du marché dans un contexte de pénurie.

La troisième est la consolidation réglementaire. L'AI Act et ses textes d'application precisent progressivement les obligations qui pesseront sur les organisations deployant des systèmes IA. Les organisations ayant anticipe ces obligations en construisant des architectures conformes by design seront avantagees par rapport a celles qui devront retrofitter des solutions non conformes.

La question n'est donc pas "faut-il construire une infrastructure IA souveraine" mais "quand commencer". La réponse rationnelle, au regard des dynamiques identifiées, est : maintenant.

Glossaire technique

Agent IA : Système informatique utilisant un modèle de langage comme moteur de raisonnement pour exécuter des séquences d'actions en vue d'atteindre un objectif.

Chunking : Découpage d'un document en segments de taille adaptée pour l'indexation dans une base vectorielle.

DPO (Direct Preference Optimization) : Technique d'alignement de modèle utilisant des paires de réponses préférées/rejetées.

Embedding : Representation numérique dense d'un texte dans un espace vectoriel, capturant sa sémantique.

Fine-tuning : Réentraînement d'un modèle pre-entraîné sur un jeu de données spécifique pour l'adapter à un domaine ou une tâche.

Inférence : Opération d'utilisation d'un modèle entraîné pour produire des sorties à partir d'entrées.

LoRA (Low-Rank Adaptation) : Technique de fine-tuning qui injecte des matrices de faible rang dans un modèle pre-entraîné, reduisant drastiquement le nombre de paramètres a ajuster.

LLM (Large Language Model) : Modèle de langage de grande taille, entraîné sur des corpus massifs de texte, capable de comprendre et générer du texte en langage naturel.

MLOps : Ensemble des pratiques d'ingénierie logicielle appliquees au cycle de vie des modèles de machine learning.

Ollama : Outil de déploiement local de LLM open source, simplifiant l'installation et l'exécution de modèles.

Orchestrateur : Composant coordonnant les interactions entre plusieurs agents et outils.

QLoRA : Variante de LoRA combinant quantification 4-bit du modèle de base et adaptation de faible rang.

RAG (Retrieval Augmented Génération) : Pattern architectural combinant recherche sémantique dans une base documentaire et génération par LLM.

vLLM : Moteur d'inférence LLM haute performance, optimise pour les environnements de production.

Références et sources

Anthropic, "Model Card Claude 3 Family", 2024. Note : utilise comme référence de comparaison de performance, non comme solution cible.

ANSSI, "Recommandations de sécurité pour les systèmes d'IA générative", version 1.0, 2024.

Commission européenne, "Règlement (UE) 2024/1689 sur l'intelligence artificielle (AI Act)", Journal officiel de l'Union européenne, 2024.

Dettmers, T., Pagnoni, A., Holtzman, A., Zettlemoyer, L., "QLoRA: Efficient Finetuning of Quantized LLMs", NeurIPS 2023.

DINUM, "Doctrine cloud au centre de l'État", version 3.0, 2024.

Gartner, "Hype Cycle for Artificial Intelligence 2024", Gartner Research, 2024.

Hu, E.J. et al., "LoRA: Low-Rank Adaptation of Large Language Models", ICLR 2022.

IDC France, "Étude sur la maturité IA des entreprises francaises", 2024.

McKinsey Global Institute, "The Economic Potential of Generative AI", 2023.

Meta AI, "Llama 3 Technical Report", 2024.

Mistral AI, "Mistral 7B", arXiv:2310.06825, 2023.

OECD, "OECD AI Principles", mis à jour 2023.

Rafailov, R. et al., "Direct Preference Optimization: Your Language Model is Secretly a Reward Model", NeurIPS 2023.

Taori, R. et al., "Stanford Alpaca: An Instruction-following LLaMA Model", Stanford CRFM, 2023.

Touvron, H. et al., "LLaMA: Open and Efficient Foundation Language Models", arXiv:2302.13971, 2023.