Protocole LLM Nehos — Transparence totale sur nos choix de modèles IA

#1. Pourquoi un Protocole LLM ? Notre engagement de transparence totale

La question revient dans chaque avant-projet : "Vous utilisez ChatGPT pour nos données ?" C'est une question légitime et trop peu d'agences y répondent clairement. Ce document existe pour y répondre sans ambiguïté, une fois pour toutes, et de façon opposable.

Ce Protocole LLM n'est pas un document marketing. C'est un engagement technique, contractuel et éthique sur la façon dont Nehos choisit, déploie et encadre les modèles de langage dans ses projets clients. Il couvre trois réalités distinctes que les acteurs du secteur mélangent souvent :

• Quels modèles nous utilisons et pourquoi (et lesquels nous évitons pour vos données)
• Ce qui entre dans les LLMs lors de nos projets — et ce qui n'y entre jamais
• Où s'exécutent les inférences — hébergement, géographie, souveraineté

Ce document s'inspire du standard émergent llms.txt (proposé en 2025 pour permettre aux sites de documenter leur usage des LLMs de façon machine-readable), mais adopte un format web complet, lisible par des humains et des moteurs de recherche. Il est versionnée, daté, et chaque modification est tracée dans le changelog en fin de page.

La transparence sur les modèles IA n'est pas qu'un geste d'honnêteté commerciale. C'est une obligation croissante : l'AI Act européen (Art. 13) impose aux fournisseurs de systèmes IA de fournir des informations claires sur le fonctionnement et les limitations de leurs systèmes. Nous prenons cette obligation au sérieux avant même qu'elle soit pleinement applicable.

#2. Les modèles LLM que Nehos utilise (et pourquoi ces choix)

Voici l'état exact de notre stack LLM en production et en R&D interne, au 3 juin 2026.

#Pourquoi Mistral Large 2 comme modèle par défaut ?

Mistral AI est une société française fondée en 2023. Ses modèles sont disponibles sur OVHcloud AI Services — hébergement français, inférences sur des GPU situés à Gravelines (Nord), données qui ne quittent pas le territoire français. C'est la solution qui offre le meilleur équilibre entre performance, souveraineté et conformité pour nos clients B2B.

Contrairement à ce qu'on lit parfois, "hébergé en Europe" ne garantit pas la même chose que "hébergé en France sur OVHcloud" : la loi CLOUD Act américaine peut contraindre des hébergeurs US (AWS, Azure, Google Cloud) à transmettre des données même stockées en UE. OVHcloud, en tant qu'acteur français, n'est pas soumis à cette législation pour ses données européennes.

#Pourquoi Claude Sonnet 4 pour les analyses complexes ?

Sur des tâches nécessitant un raisonnement à plusieurs niveaux — revue de contrats, analyse d'impact réglementaire, rédaction technique avec contraintes précises — Claude Sonnet 4 d'Anthropic produit des résultats mesurément supérieurs à l'état de l'art au moment de la rédaction de ce document. Nous l'utilisons via AWS Bedrock, région eu-west-1 (Irlande). Les données sont anonymisées avant transmission ; Anthropic ne réentraîne pas ses modèles sur les données traitées via API commerciale.

#Pourquoi GPT-4o n'est jamais utilisé pour les données clients ?

OpenAI est une entreprise américaine. Même via Azure West Europe, les inférences peuvent être soumises à la juridiction américaine. Nos standards de souveraineté pour les projets B2B excluent ce modèle de tout usage en production avec des données clients réelles. GPT-4o reste dans notre stack uniquement pour la R&D interne de Nehos — prototypage rapide, tests de benchmark, explorations de prompting — où aucune donnée client n'est impliquée.

#3. Ce que nos projets clients envoient aux LLMs — et ce qui n'y entre jamais

Chaque requête envoyée à un LLM en production comporte un contexte d'inférence. Voici ce que ce contexte peut légitimement contenir dans nos projets, et ce qui en est systématiquement exclu.

#Ce qui peut entrer (avec validation préalable)

• Questions des utilisateurs finaux — anonymisées selon la configuration du projet. En pratique : les noms propres, identifiants de compte, numéros de dossier sont masqués ou remplacés avant envoi au LLM.
• Documents indexés par RAG — uniquement avec permission documentée du client et liste des sources validée en amont de la mise en production. Les documents soumis au secret professionnel (avis d'avocats, rapports médicaux) nécessitent une validation spécifique.
• Historique de conversation — au niveau de la session uniquement. Aucun historique persistant entre sessions sauf configuration explicite, documentée et acceptée contractuellement par le client.
• Données de configuration système — les prompts système, instructions de rôle, paramètres métiers définis par le client pendant le projet.

#Ce qui n'entre jamais, sans exception

• Données personnelles nominatives non anonymisées — noms complets associés à des informations sensibles, adresses, numéros d'identification (RGPD Art. 4 et Art. 9)
• Données financières confidentielles — bilans non publiés, données de trésorerie, informations couvertes par NDA signé
• Secrets industriels et brevets — formules, procédés, codes sources propriétaires non destinés au système IA
• Données de santé — toute donnée relevant de l'Art. 9 RGPD (données biométriques, diagnostics, dossiers médicaux), sauf projet on-premise spécifique avec DPIA validée et consentement explicite
• Identifiants, mots de passe, clés API — interdits absolus, filtrés automatiquement par nos pipelines de pré-traitement

Ces règles ne sont pas que documentées : elles sont implémentées techniquement dans nos pipelines de préparation des données (couches de filtrage, validation de schémas, détection automatique de PII via NER avant inférence).

#4. Hébergement et souveraineté : où les inférences s'exécutent

La géographie des inférences a des conséquences juridiques concrètes. Voici notre cartographie exacte.

OVHcloud Gravelines (GRA) — France : Mistral Large 2 pour les projets en production standard. Acteur français, non soumis au CLOUD Act américain, certifié SecNumCloud pour les données les plus sensibles, conforme RGPD par construction.

OVHcloud Beauharnois (BHS) — Canada : Mistral NeMo 12B pour les fine-tunings et cas d'usage à faible criticité. Le Canada dispose d'une décision d'adéquation RGPD (article 45 RGPD) — les transferts sont légaux sans mécanisme complémentaire. L'option de basculer sur OVHcloud France est disponible sur demande.

AWS eu-west-1 — Irlande : Claude Sonnet 4 et Claude Haiku 3.5 via Amazon Bedrock. L'Irlande est un État membre de l'UE ; les données restent dans l'espace européen. AWS est un prestataire américain soumis au CLOUD Act, ce qui explique pourquoi nous y envoyons uniquement des données anonymisées.

Infrastructure client — variable : Llama 3.1 70B en mode on-premise. L'inférence se déroule entièrement chez le client, sur ses propres serveurs. Nehos ne voit jamais les données qui transitent. C'est la configuration applicable aux projets réglementés : santé, défense, infrastructure critique.

Azure West Europe — Pays-Bas : GPT-4o, R&D interne Nehos uniquement. Données Nehos exclusivement, jamais de données clients.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#5. Données d'entraînement : ce que nous savons et ce que nous ignorons

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

Une question souvent posée, rarement répondue honnêtement : est-ce que les données envoyées à un LLM servent à l'entraîner ?

#Ce que nous savons avec certitude

Mistral via OVHcloud AI Services : les conditions contractuelles d'OVHcloud stipulent explicitement que les données d'inférence ne sont pas utilisées pour l'entraînement des modèles Mistral. C'est un engagement contractuel opposable.

Claude via AWS Bedrock : la politique d'Anthropic pour l'API commerciale (hors offre gratuite) indique que les données de production ne sont pas utilisées pour l'entraînement. L'accord de traitement des données (DPA) AWS Bedrock inclut ces garanties.

Llama on-premise : Llama 3.1 est un modèle open-weights. L'inférence se passe sur l'infrastructure client. Meta ne voit jamais les données. Il n'y a pas d'entraînement continu en mode on-premise.

#Ce que nous ignorons (honnêteté sur les limites)

Les pratiques des fournisseurs LLM évoluent. Nous ne pouvons pas garantir que les politiques décrites ci-dessus ne seront pas modifiées dans le futur. Ce protocole est mis à jour à chaque changement significatif de nos fournisseurs. Si un changement de politique d'un fournisseur nous amenait à modifier nos pratiques de façon substantielle, nous en informerions nos clients concernés avant tout changement opérationnel.

Nous ne savons pas non plus, avec une certitude absolue, quelles données ont servi à pré-entraîner les versions actuelles de ces modèles — ces informations ne sont pas intégralement publiées par les fournisseurs. Cette opacité est un problème sectoriel que nous reconnaissons ouvertement.

#6. Notre hiérarchie de choix des modèles selon le cas d'usage

Notre processus de sélection du modèle n'est pas laissé à l'appréciation individuelle de chaque consultant. Il suit une hiérarchie documentée, appliquée à chaque projet.

Niveau 1 — Par défaut pour tout projet en production : Mistral Large 2 sur OVHcloud France. Souverain, performant, conforme. C'est le point de départ systématique pour les agents IA, les systèmes RAG et les chatbots B2B.

Niveau 2 — Si les exigences de raisonnement dépassent les capacités de Mistral Large 2 : Claude Sonnet 4 via AWS Bedrock eu-west-1, avec anonymisation préalable des données. Le passage au Niveau 2 est documenté dans les specs techniques du projet et validé avec le client.

Niveau 3 — Si la contrainte on-premise est absolue : Llama 3.1 70B déployé sur l'infrastructure du client. Applicable pour les projets médicaux, de défense, d'infrastructure critique, ou tout contexte où les données ne peuvent physiquement pas quitter les locaux du client.

Exclu de la hiérarchie production : GPT-4o. Usage interne Nehos R&D uniquement, jamais pour des données clients.

Cette hiérarchie est réexaminée semestriellement. Si un nouveau modèle (Mistral Medium 3, Claude Opus 5, Llama 4...) offre de meilleures garanties de souveraineté et de performance, nous l'évaluons et l'intégrons à la hiérarchie si pertinent, avec mise à jour de ce protocole.

#7. Conformité AI Act : les articles qui s'appliquent à nos pratiques

L'AI Act (Règlement UE 2024/1689, applicable progressivement à partir d'août 2024) impose des obligations spécifiques aux fournisseurs et déployeurs de systèmes IA. Voici comment ce protocole répond aux articles pertinents.

Article 13 — Transparence et fourniture d'informations : Les systèmes IA à risque limité doivent être conçus et développés de façon à assurer un niveau suffisant de transparence. Ce protocole LLM est notre réponse opérationnelle à cet article — un document public, lisible, mis à jour, qui décrit précisément les modèles utilisés et les traitements effectués.

Article 52 — Obligations de transparence pour certains systèmes IA : Les systèmes conversationnels (chatbots, agents IA) doivent informer les utilisateurs finaux qu'ils interagissent avec un système IA. Tous nos déploiements d'agents incluent une mention explicite au démarrage de la session.

Article 9 — Système de gestion des risques : Pour les systèmes IA à risque limité ou élevé, une évaluation des risques doit être réalisée. Nous conduisons une évaluation de risque documentée pour chaque déploiement d'agent IA en production, avec revue annuelle.

Notre offre conformité AI Act accompagne les entreprises dans la mise en conformité avec l'ensemble du règlement.

#8. Mises à jour de ce protocole : versioning et changelog

Ce document est versionnée. Chaque modification substantielle — changement de fournisseur, ajout d'un modèle, modification d'une règle de filtrage, évolution des garanties contractuelles d'un fournisseur — fait l'objet d'une nouvelle version datée.

#Changelog

Les prochaines révisions prévues : évaluation de Mistral Medium 3 (disponibilité via OVHcloud), réévaluation des garanties AWS Bedrock suite à la mise à jour des DPA Anthropic prévue T3 2026.

Contact pour questions techniques sur ce protocole : Chokri Siala, CTO Nehos Groupe — chokri@nehos-groupe.com.