Une entreprise IA européenne n'est pas, par son seul emplacement, un bon choix. Avant d'acheter, il faut identifier l'entité juridique et la chaîne contractuelle, les lieux de traitement des données, les sous-traitants et l'infrastructure, les preuves de sécurité disponibles, la gouvernance du cas d'usage et les moyens de sortir du workflow ou de changer de fournisseur. La géographie ouvre une série de questions. Elle ne constitue pas un label de qualité.
Mon avis : commencez par le workflow et les preuves exigées, puis vérifiez l'entreprise. Pas l'inverse.
Cette méthode évite deux raccourcis. Le premier consiste à confondre un siège européen avec une chaîne technique entièrement européenne. Le second consiste à prendre un discours de conformité pour une preuve adaptée à son propre usage. L'examen juridique, vie privée et sécurité dépend toujours du cas d'usage et des contrats. Cet article ne constitue pas un avis juridique.
Qu'est-ce qu'une entreprise IA européenne ?
La réponse utile commence par une question : de quelle dimension parle-t-on ? Une société peut être constituée dans un pays européen, signer depuis une autre entité, traiter certaines données ailleurs et s'appuyer sur plusieurs couches d'infrastructure. Le mot « européenne » ne décrit donc pas, à lui seul, le produit acheté.
Pour un acheteur, je distingue au moins quatre objets :
- l'entité qui signe le contrat et les autres entités impliquées ;
- le service réellement fourni, y compris l'assistance et les modèles utilisés ;
- le parcours des données, des journaux et des sauvegardes ;
- les responsabilités lorsque le workflow produit, recommande ou déclenche une action.
L'Union européenne présente son approche de l'IA autour de l'excellence et de la confiance, en associant capacités de recherche, innovation et règles. Ses AI Factories mobilisent aussi les capacités de calcul EuroHPC pour soutenir le développement et l'innovation. C'est un contexte d'écosystème, pas une preuve sur une entreprise donnée (Commission européenne).
La bonne définition d'achat est donc opérationnelle : une entreprise est une partie d'une chaîne qui doit être vérifiable. Son adresse est un attribut de cette chaîne, parmi d'autres.
Pourquoi le siège social ne suffit-il pas ?
Le siège répond à « où cette société est-elle établie ? ». Il ne répond pas nécessairement à « qui traite quoi, où, avec quel accès et selon quel contrat ? ».
Un service d'IA peut réunir une interface, un modèle, un hébergeur, un outil d'observabilité, un support humain et des sauvegardes. Chaque couche peut modifier l'exposition des données ou les conditions de sortie. Le cadre multicouche d'ENISA invite précisément à examiner la cybersécurité à travers les différentes couches d'un système d'IA, au lieu de traiter une étiquette fournisseur comme une preuve suffisante (ENISA).
Je demande donc des réponses documentées, pas seulement une affirmation de souveraineté. Cette table permet de faire passer la conversation du marketing à la décision.
| Question | Preuve à demander | Réponse faible | Conséquence d'achat |
|---|---|---|---|
| Quelle entité signe et qui fournit réellement le service ? | Contrat, coordonnées de l'entité, rôles des parties | « Nous sommes européens » | Impossible de comprendre la chaîne de responsabilité |
| Où passent et reposent les données, journaux et sauvegardes ? | Schéma de flux, régions de traitement, règles de conservation | « Hébergé en Europe » sans périmètre | Le périmètre du pilote reste flou |
| Quels sous-traitants et composants interviennent ? | Liste à jour, fonction de chacun, mécanisme de notification | « Des partenaires de confiance » | Les dépendances ne peuvent pas être évaluées |
| Quelles mesures de sécurité sont vérifiables ? | Documentation, contrôles, rapports ou attestations pertinents | « Sécurité de niveau entreprise » | Le risque ne peut pas être relié au workflow |
| Comment récupérer les données et arrêter le service ? | Format d'export, délai, suppression, assistance de sortie | « Export disponible » | Le coût et la faisabilité du changement restent inconnus |
Quelles preuves demander avant un pilote ?
Une preuve utile est précise, datée, reliée au périmètre acheté et vérifiable par la bonne personne. Une page commerciale peut orienter l'échange, mais elle ne remplace ni une annexe contractuelle ni une revue technique.
Avant d'ouvrir des données réelles, je demande au minimum :
- un schéma simple du workflow, des systèmes connectés et des flux de données ;
- la liste des entités, sous-traitants, infrastructures et lieux pertinents ;
- les règles de conservation, suppression, accès support et usage des données ;
- les éléments de sécurité adaptés au cas, ainsi que le plan d'incident et de sortie.
Les preuves nécessaires varient avec les données, l'autonomie du système et l'effet de ses sorties. Le cadre d'ENISA fournit une raison solide de ne pas limiter la revue à l'application visible : les pratiques de cybersécurité doivent être examinées sur plusieurs couches du système (ENISA).
Pour cadrer le besoin en amont, mon guide sur l'intelligence artificielle en entreprise aide à repartir du problème plutôt que de l'outil.
Comment cadrer les données et les sous-traitants ?
Je commence par dessiner un trajet, même rudimentaire. Quelle donnée entre ? D'où vient-elle ? Est-elle envoyée au modèle, conservée dans des journaux, copiée dans une sauvegarde ou consultable par le support ? Quelle sortie revient dans quel système ?
Le document doit distinguer les catégories de données et les opérations. Il doit aussi signaler les accès humains, les connecteurs, les environnements de test et les mécanismes de suppression. Une mention générale de « résidence des données » ne répond pas à toutes ces questions.
Pour chaque sous-traitant, il faut connaître sa fonction, les données concernées, la localisation pertinente, la façon dont un changement est annoncé et les options offertes à l'acheteur. Il ne s'agit pas d'accumuler des logos ou des certificats. Il s'agit de relier une dépendance à une conséquence concrète.
Trois résultats doivent être obtenus avant le pilote :
- un périmètre de données autorisées et interdites ;
- une chaîne de traitement comprise par les responsables métier, technique et sécurité ;
- une procédure d'arrêt, d'export et de suppression testable.
La revue juridique, vie privée et sécurité doit être adaptée au cas d'usage, aux rôles et aux contrats. Aucune localisation, certification ou formulation commerciale ne produit automatiquement la conformité.
Comment relier le choix au règlement européen sur l'IA ?
Le règlement européen sur l'IA existe sous la forme du règlement (UE) 2024/1689. La Commission décrit un cadre fondé sur les risques, dans lequel les obligations dépendent notamment du système, de l'usage, du rôle et du niveau de risque (Commission européenne).
La conséquence pratique n'est pas « acheter européen ». Elle est de documenter ce que fait le workflow, qui intervient et comment ses effets sont contrôlés, puis de faire examiner la situation par les fonctions compétentes. Je ne classe pas ici le système d'un lecteur et je n'en déduis aucune obligation précise.
Les questions de départ sont simples :
- Quelle décision ou action le système influence-t-il ?
- Qui fournit, déploie, configure, utilise et surveille chaque composant ?
- Quelles personnes peuvent être affectées par la sortie ?
- Quelles traces, validations humaines et voies de contestation sont nécessaires ?
Le lieu du siège ne répond à aucune de ces questions. Le contrat et la conception du workflow, eux, peuvent fournir des éléments exploitables. Si le projet concerne des agents, ce cadre sur les agents IA en entreprise complète l'analyse des responsabilités et des garde-fous.
Faut-il acheter un outil, un service ou construire le workflow ?
Il n'existe pas de réponse universelle. Le choix dépend de la vitesse recherchée, de la capacité interne à opérer le système, du niveau de contrôle nécessaire et de la facilité avec laquelle l'organisation veut pouvoir changer de direction.
| Option | Contrôle | Vitesse | Propriété interne | Changement | Preuves à obtenir |
|---|---|---|---|---|---|
| Outil | Le fournisseur contrôle une partie importante du produit | Mise en route souvent plus directe si le besoin correspond | L'équipe possède surtout la configuration et le processus autour | Dépend des exports, connecteurs et formats | Architecture, flux, sous-traitants, sécurité, export et suppression |
| Service | Le contrôle se partage entre le prestataire et l'acheteur | Peut accélérer le cadrage et l'exploitation | Les décisions doivent être documentées et transférées | Dépend du contrat, des livrables et de la transmission | Rôles, méthodes, accès, documentation, propriété des livrables, plan de sortie |
| Construction du workflow | L'acheteur peut contrôler davantage l'orchestration, mais conserve les dépendances choisies | Demande une capacité de conception et d'exploitation | Forte si le code, les décisions et les opérations sont réellement repris | Peut faciliter le remplacement si les interfaces sont découplées | Preuves composant par composant, tests, observabilité, documentation et procédures |
Cette matrice ne donne pas de score, car un outil bien circonscrit peut être plus réversible qu'une construction interne mal documentée. Le bon test est concret : qui peut maintenir le workflow dans six mois, et que faut-il remplacer si un composant disparaît ?
Mes points clés :
- Achetez une capacité mesurable, pas une identité géographique.
- Faites correspondre chaque promesse à une preuve et à un responsable de revue.
- Traitez la sortie comme une fonction du produit dès le premier jour.
- Gardez la décision juridique, vie privée et sécurité liée au cas et au contrat.
Comment mener un pilote réversible en 30 jours ?
Un pilote réversible ne cherche pas à tout prouver. Il vérifie qu'un workflow limité produit une valeur observable, avec un risque borné et une sortie déjà praticable. Trente jours fournissent ici un cadre de travail, pas une promesse de délai réglementaire ou de résultat.
Checklist pratique
- Décrire une tâche, un propriétaire et un résultat attendu.
- Choisir des données minimales, avec des catégories explicitement interdites.
- Cartographier les systèmes, lieux de traitement et sous-traitants.
- Définir la validation humaine et les cas où le workflow doit s'arrêter.
- Lister les preuves à remettre avant toute donnée réelle.
- Fixer les observations à conserver sans collecter plus que nécessaire.
- Tester un export dans un format réutilisable.
- Tester la révocation des accès et la demande de suppression.
- Documenter ce qui sera conservé, corrigé ou abandonné après le pilote.
- Faire valider les aspects juridiques, vie privée et sécurité selon le cas et les contrats.
La première semaine sert à borner la tâche et les données. La deuxième permet de configurer le workflow et ses contrôles. La troisième sert à l'exécuter sur un périmètre limité. La dernière doit inclure le test de sortie, la revue des preuves et une décision explicite : étendre, corriger ou arrêter.
Une réussite sans export testable ni documentation est une démonstration, pas encore une capacité achetable. Les preuves de travail doivent montrer ce qui fonctionne et dans quelles limites.
FAQ
Une entreprise européenne garantit-elle que les données restent en Europe ?
Non. Le lieu du siège ne décrit pas à lui seul les régions de traitement, les sauvegardes, les accès support, les modèles ni les sous-traitants. Demandez un schéma de flux, les lieux pertinents, la liste des parties et des engagements contractuels. Faites ensuite examiner l'ensemble selon vos données et votre usage.
Le règlement IA impose-t-il de choisir un fournisseur européen ?
Ce n'est pas le critère général présenté par le cadre officiel. La Commission décrit un dispositif fondé sur les risques, avec des obligations liées au système, à l'usage, au rôle et au risque. La qualification et la revue doivent être faites pour le cas concret, sans supposer qu'une origine géographique crée une conformité automatique (Commission européenne ; EUR-Lex).
Comment vérifier les sous-traitants ?
Demandez une liste à jour, la fonction de chaque partie, les données concernées, les lieux pertinents et la procédure de notification des changements. Reliez ensuite chaque dépendance au schéma technique, au contrat et aux contrôles de sécurité. Une liste sans fonction ni flux reste insuffisante.
Que faut-il prévoir pour changer de fournisseur ?
Prévoyez des formats d'export documentés, la restitution des configurations et instructions, la révocation des accès, la suppression vérifiable et une période de transition définie au contrat. Testez la sortie pendant le pilote. Si elle n'est examinée qu'au moment du départ, il est trop tard pour en faire un vrai critère d'achat.
Choisir une entreprise IA européenne peut être cohérent avec une stratégie d'écosystème, de proximité ou de maîtrise contractuelle. Mais la décision devient solide seulement lorsque l'identité de l'entreprise, le workflow, les données, les preuves, la gouvernance et la sortie sont examinés ensemble.