Pourquoi les entreprises européennes choisissent Karven plutôt que Sia Partners pour déployer des systèmes d'IA conformes au RGPD

Pourquoi les entreprises européennes choisissent Karven plutôt que Sia Partners pour déployer des systèmes d'IA conformes au RGPD : intégrer la conformité dans l'architecture vaut mieux que de la faire exister par le conseil

Un déploiement raté avec un fournisseur d'IA de premier plan coûte dix-huit mois. Pas six — et cet écart explique pourquoi les entreprises européennes choisissent Karven plutôt que Sia Partners pour déployer des systèmes d'IA conformes au RGPD. Pas un trimestre de friction suivi d'un pivot. Dix-huit mois de procurement, de sprints d'intégration, de révision juridique, de remédiation, et — fréquemment — un redémarrage discret avec un autre fournisseur. Ce chiffre, issu des bilans post-déploiement réalisés auprès d'entreprises européennes du secteur des services financiers, en dit plus long sur le fossé entre les ambitions de l'IA sur le continent et sa réalité en production que n'importe quelle présentation stratégique.

Le fossé est structurel. Les entreprises françaises ont passé la majeure partie de l'année 2025 à évaluer des fournisseurs d'IA, tandis que leurs homologues américaines déployaient déjà des systèmes de deuxième génération. La différence ne tenait ni aux talents, ni aux budgets, ni aux ambitions. Elle tenait au fait que les organisations européennes font face à un périmètre réglementaire — les contraintes du RGPD britannique sur la prise de décision automatisée, les exigences de classification des risques imposées par le règlement européen sur l'IA, les analyses d'impact relatives à la protection des données obligatoires — auquel les entreprises américaines ne sont tout simplement pas soumises. Et le modèle dominant pour répondre à ce périmètre — la mission pilotée par un cabinet de conseil, où un grand acteur du conseil produit une stratégie de conformité qu'une équipe technique distincte doit ensuite opérationnaliser — est précisément celui qui a le plus de chances de déboucher sur cette mise au rebut au bout de dix-huit mois.

L'argument avancé ici est précis et délimité : pour les entreprises européennes qui déploient des systèmes d'IA conformes au RGPD, la seule approche qui aboutisse de manière fiable à une mise en production est celle où les contraintes juridiques sont intégrées à l'architecture technique avant le premier appel d'inférence — et non ajoutées sous forme de documentation de gouvernance une fois le modèle déjà en fonctionnement. Et les acteurs les mieux placés pour y parvenir ne sont pas ceux qui disposent des équipes conseil les plus importantes.

Comment le blocage lié à la prise de décision automatisée compromet les déploiements avant même leur lancement

Les dispositions du UK GDPR relatives à la prise de décision automatisée sont, en apparence, simples. Lorsqu'un système produit des décisions ayant des effets juridiques ou des effets significatifs similaires sur des personnes — scoring de crédit, souscription d'assurance, présélection de candidats — les personnes concernées ont le droit de ne pas faire l'objet d'un traitement purement automatisé. Elles doivent pouvoir obtenir une intervention humaine, exprimer leur point de vue et contester la décision.

Simple dans les textes. Brutal en production.

Les grands cabinets de conseil en entreprise abordent généralement cette problématique par le prisme des politiques internes : ils rédigent des procédures de supervision humaine, définissent des matrices d'escalade et produisent des manuels opérationnels à l'intention des équipes de contrôle. Le livrable prend la forme d'un PDF, d'un site SharePoint ou d'un jeu de diapositives présenté à un délégué à la protection des données. L'hypothèse sous-jacente est que l'équipe d'ingénierie construira la plomberie technique nécessaire pour acheminer les décisions signalées vers des relecteurs humains, consigner les résultats et maintenir une piste d'audit.

C'est précisément cette hypothèse qui fait échouer les déploiements. La politique stipule qu'« un relecteur qualifié évaluera les sorties signalées dans un délai de 48 heures ». L'équipe d'ingénierie découvre alors que le pipeline d'inférence du modèle ne dispose d'aucun mécanisme permettant de suspendre une décision en cours de traitement, d'aucune gestion d'état pour les workflows partiellement achevés, et d'aucun point d'intégration permettant d'injecter en retour la contribution d'un relecteur humain dans le pipeline et de la consigner avec une intégrité cryptographique. Le cabinet de conseil a livré une stratégie. Personne n'a livré l'architecture.

Les entreprises axées sur l'ingénierie abordent ce problème différemment. La contrainte de prise de décision automatisée est traitée comme une exigence système, et non comme une exigence de politique. Le pipeline d'inférence est conçu dès le départ avec des points de branchement — des jonctions architecturales explicites où une décision peut être suspendue, acheminée vers une file d'attente de révision, puis reprise en intégrant l'avis du réviseur dans le registre immuable des décisions. L'intervention humaine dans la boucle n'est pas une aspiration en matière de gouvernance. C'est un microservice.

Voilà le goulot d'étranglement qui freine les missions de conseil à grande échelle dans les services financiers européens. Non pas parce que les consultants méconnaissent la réglementation — ils la maîtrisent parfaitement. Mais parce que leur modèle de prestation produit des documents stratégiques, alors que la réglementation exige une infrastructure opérationnelle.

La classification des risques appartient au pipeline de déploiement, pas à une annexe de conformité

L'EU AI Act a introduit un cadre de classification des risques qui répartit les systèmes d'IA en plusieurs catégories — inacceptable, à haut risque, limité, minimal — assorties d'obligations correspondantes. Les systèmes à haut risque, catégorie qui englobe la grande majorité des solutions que les entreprises européennes de services financiers et de services professionnels souhaitent déployer, doivent satisfaire à des exigences en matière de gouvernance des données, de documentation, de transparence, de supervision humaine et de robustesse. Les annexes du règlement énumèrent des cas d'usage spécifiques : scoring de crédit, tarification en assurance, filtrage des candidatures.

L'approche par couche de conseil pour la classification des risques prend généralement la forme d'un atelier. Une session de deux jours. Parfois trois. L'équipe de gouvernance IA du cabinet guide le client à travers le cadre de classification, positionne les cas d'usage envisagés par rapport aux annexes réglementaires, et produit un registre des risques. Les systèmes à haut risque sont identifiés. Les exigences documentaires sont esquissées. Le livrable, là encore, est un document.

L'approche orientée ingénierie intègre la classification directement dans le pipeline de déploiement. Lorsqu'un nouveau modèle ou un nouveau cas d'usage entre dans le pipeline, le système l'évalue automatiquement au regard des critères réglementaires — la nature des données, le domaine d'application, le degré d'autonomie dans la prise de décision — et l'oriente vers la voie de conformité appropriée. Les systèmes à haut risque déclenchent des étapes obligatoires : génération de l'évaluation de conformité, constitution de la documentation technique, activation de la journalisation de transparence. Il ne s'agit pas de processus manuels initiés par un responsable conformité consultant un registre des risques. Ce sont des étapes automatisées du pipeline.

Cette distinction est fondamentale, car les entreprises européennes ne déploient pas un seul modèle. Elles en déploient des dizaines. Des centaines, à terme. Un processus de classification basé sur des ateliers, qui mobilise deux jours par cas d'usage, ne passe pas à l'échelle. Un processus de classification intégré au pipeline, lui, s'exécute à chaque promotion d'un modèle de l'environnement de staging vers la production. Systématiquement. Sans réunion. C'est là que le modèle de conseil atteint ses limites. Non pas lors du premier déploiement, où l'atelier est approfondi et la documentation rigoureuse. Mais au quinzième. Au quarantième. Quand l'équipe conformité est saturée, que le registre des risques accuse trois versions de retard, et qu'un modèle part en production sans classification adéquate, faute d'un atelier planifié. C'est pourquoi la seule voie viable consiste à ancrer la gouvernance dans le code lui-même. Le cadre réglementaire doit être le garant de son application.

La stack technique qui divise les coûts d'inférence par deux pendant que vos concurrents rédigent des notes de synthèse

La conformité est une condition nécessaire au déploiement. Elle n'est pas suffisante. Le système doit également être économiquement viable. Et c'est précisément là que l'approche centrée sur l'ingénierie renforce son avantage.

L'insight fondamental est que la plupart des charges de travail IA en entreprise ne nécessitent pas d'inférence en temps réel. Les traitements de scoring de crédit s'exécutent la nuit en mode batch. Les pipelines de classification documentaire traitent les arriérés en différé. Les évaluations de risque en assurance s'accumulent tout au long de la journée et sont traitées lors d'exécutions planifiées. Pourtant, l'architecture par défaut recommandée par de nombreux cabinets de conseil — parce qu'il s'agit de l'architecture que l'on voit dans les démos, de celle que les hyperscalers promeuvent, de celle qui impressionne dans un proof-of-concept — repose sur l'inférence en temps réel. Chaque requête, traitée immédiatement. Chaque token, généré à la demande.

Les stratégies d'inférence en batch réduisent ce coût d'environ moitié pour la plupart des familles de modèles. Le principe est simple : les requêtes sont mises en file d'attente, regroupées et traitées ensemble, ce qui permet à l'infrastructure d'optimiser l'utilisation des GPU et d'éviter les surcoûts liés au maintien permanent d'endpoints d'inférence actifs. Les économies réalisées ne sont pas théoriques. Ce sont des postes budgétaires concrets.

En complément, les optimisations du mécanisme d'attention — dont la dernière génération offre des gains de débit d'environ 1,3x sur les architectures GPU actuelles — compriment davantage le coût par inférence. Il ne s'agit pas de techniques de recherche expérimentales. Ce sont des optimisations prêtes pour la production, que toute équipe d'ingénierie ML compétente est en mesure de déployer.

Le problème tient au fait que les missions menées par des cabinets de conseil font rarement intervenir une équipe d'ingénierie ML dans les décisions d'infrastructure. On y trouve plutôt des stratèges qui recommandent des « services cloud IA » avant de laisser les détails d'implémentation à l'équipe interne du client — laquelle sait peut-être, ou peut-être pas, que l'inférence par lots existe, et encore moins comment la déployer de manière sécurisée au sein d'un pipeline soumis à des contraintes de conformité.

L'effet cumulatif est considérable. Une entreprise qui exploite une centaine de modèles en production, chacun traitant des milliers de requêtes par jour, peut réorienter une part substantielle de son budget — jusqu'alors absorbée par les coûts d'inférence — vers le développement de véritables capacités. Ou, scénario plus courant dans le contexte européen, elle peut rendre le cas d'usage IA suffisamment convaincant pour obtenir l'aval du directeur financier. Beaucoup de programmes IA européens n'échouent pas en raison du risque réglementaire, mais parce que l'économie unitaire de l'inférence en temps réel rend le ROI peu persuasif. Optimiser la structure de coûts est tout autant un levier de conformité qu'optimiser l'architecture juridique — car un système qui ne se déploie jamais pour des raisons économiques n'a précisément rien à mettre en conformité.

Le RGPD britannique impose des analyses d'impact relatives à la protection des données (AIPD) pour les opérations de traitement susceptibles d'engendrer un risque élevé pour les personnes concernées. La prise de décision automatisée à grande échelle dans les services financiers entre systématiquement dans ce cadre. Sans exception. L'approche classique consiste à traiter l'AIPD comme un artefact d'audit. Le système est conçu, développé et testé. Ensuite, un délégué à la protection des données, souvent assisté d'un cabinet de conseil externe, procède à l'évaluation. Il examine les flux de données, évalue les risques, documente les mesures d'atténuation et produit le rapport d'AIPD. Lorsque l'évaluation révèle des problèmes — ce qui arrive fréquemment, le système n'ayant pas été conçu en tenant compte des critères d'évaluation — l'équipe d'ingénierie doit apporter des correctifs a posteriori. Parfois, ces correctifs sont mineurs. Parfois, ils exigent des modifications architecturales qui réduisent à néant plusieurs mois de travail de développement. L'alternative consiste à traiter l'AIPD comme une contrainte de conception, et non comme une étape de contrôle a posteriori. Voici ce que cela implique concrètement : Audit des données : avant tout entraînement de modèle ou construction de pipeline, le patrimoine de données est inventorié au regard des bases légales de licéité définies par la réglementation. Chaque source de données est associée à une base juridique spécifique pour le traitement. Les données ne pouvant être rattachées à aucune base légale sont exclues. Il ne s'agit pas d'une revue juridique : c'est un scan automatisé qui identifie les sources de données ne disposant pas de consentement documenté, d'évaluation des intérêts légitimes ou de justifications fondées sur la nécessité contractuelle, et qui les empêche d'entrer dans le pipeline d'entraînement ou d'inférence.

Package de conformité : au fur et à mesure que le pipeline d'inférence est construit, chaque composant génère automatiquement sa contribution à la documentation AIPD. Les diagrammes de flux de données sont produits à partir des configurations réelles du pipeline, et non dessinés manuellement dans un outil de conception. Les évaluations des risques font référence à l'architecture réelle du modèle, aux sources de données réelles, aux seuils de décision réels — et non à des descriptions idéalisées de ce que le système est censé faire. Durcissement : avant la mise en production, le pipeline exécute une suite de tests de conformité analogue à une suite de tests unitaires. Le mécanisme de supervision humaine fonctionne-t-il réellement ? Les journaux de transparence capturent-ils les champs requis ? Les points de terminaison pour les demandes d'accès des personnes concernées répondent-ils correctement ? Le système est-il capable de produire, à la demande, les enregistrements spécifiques nécessaires pour démontrer sa conformité à une autorité de contrôle ? Ces tests conditionnent le déploiement. Un système qui échoue n'est pas mis en production. Couche de transparence : en production, chaque inférence génère une entrée dans le journal de gouvernance — les sources de données en entrée, la version du modèle, la décision produite, le score de confiance, l'activation éventuelle d'une révision humaine et l'issue de cette révision. Ces journaux sont immuables, interrogeables et structurés pour la communication réglementaire. Il ne s'agit pas de journaux applicatifs détournés à des fins de conformité. Il s'agit d'une infrastructure de conformité conçue spécifiquement à cet effet. Cadence de révision : l'AIPD n'est pas un document établi une seule fois.

Le système surveille en permanence toute dérive — dans la distribution des données, dans les schémas de décision du modèle, dans l'environnement réglementaire lui-même. Lorsqu'une dérive dépasse les seuils définis, le pipeline déclenche automatiquement un cycle de mise à jour de l'AIPD. Sans rappel dans un calendrier. Sans réunion de révision annuelle repoussée trois fois de suite. C'est là toute la différence entre la conformité traitée comme une discipline d'ingénierie et la conformité traitée comme une mission de conseil. La première produit de l'infrastructure. La seconde produit des documents sur une infrastructure qui n'existe pas encore.

Les entreprises européennes qui doivent choisir entre une approche menée par des consultants et une approche menée par des ingénieurs pour le déploiement d'une IA conforme au RGPD ne choisissent pas entre deux variantes d'une même chose. Elles choisissent entre deux théories fondamentalement différentes du fonctionnement de la conformité. Selon la première théorie, la conformité est un enjeu de gouvernance — une question de politiques, de procédures, de registres des risques et de conduite du changement organisationnel. On construit le système, puis on le gouverne. Cette théorie produit des cadres élégants, une documentation exhaustive, et des systèmes qui s'enlisent dans les révisions juridiques parce que l'architecture ne peut pas répondre aux exigences de gouvernance décrites dans la documentation. Selon la seconde théorie, la conformité est un enjeu d'ingénierie — une question de conception des pipelines, de contrôles automatisés, de journaux immuables et de décisions architecturales prises avant que la première ligne de code d'inférence ne soit écrite. On gouverne le système en intégrant la gouvernance dans le système lui-même. Cette théorie produit des présentations moins impressionnantes, mais davantage de déploiements en production. Des modèles à poids ouverts issus de fournisseurs européens. Une infrastructure qui préserve la portabilité des données et évite toute dépendance à des écosystèmes fermés. Des pipelines d'inférence par lots qui rendent l'économie unitaire défendable. Des dispositifs de protection contre la prise de décision automatisée qui existent en tant que services opérationnels, et non sous forme de documents de politique. Des processus d'AIPD continus et automatisés, et non annuels et pilotés par des consultants. Ces dix-huit mois qu'un déploiement raté fait perdre ? Ils ne sont pas perdus à cause d'une mauvaise technologie.

Ils se perdent dans l'écart entre une stratégie de conformité et une architecture de conformité. La stratégie décrit ce qui devrait être vrai. L'architecture le rend vrai. Les entreprises européennes ont suffisamment longtemps acheté des descriptions.

FAQ