Prouvez-le, 1re partie : Pourquoi « probablement correct » n’est pas suffisant pour votre start-up spécialisée dans l’IA

Les start-ups qui s’imposeront à l’ère de l’IA ne se distingueront pas par leurs modèles les plus avancés ou leurs jeux de données d’apprentissage les plus volumineux, mais par la confiance qu’elles inspirent. Ce qui fera la différence, c’est de savoir si les utilisateurs leur font confiance et si elles sont capables de répondre à la question « Que se passe-t-il lorsque votre IA se trompe ? » avec une certitude mathématique, et non pas seulement une assurance probabiliste. Sur les marchés réglementés, la vérification prend de plus en plus d’importance par rapport à la seule capacité des modèles.

Vous venez de clôturer votre tour de table d’amorçage. Votre assistant de crédit basé sur l’IA a été mis en service la semaine dernière auprès de 200 utilisateurs bêta. Le troisième jour, un client a fait une capture d’écran de votre chatbot lui indiquant qu’il remplissait les conditions pour obtenir un prêt immobilier classique avec un apport de 8 %. Il l’a publiée sur les réseaux sociaux. Or, votre politique exige un apport de 20 %.

Votre cofondateur est le premier à le voir. Votre investisseur est le deuxième. Votre conseiller juridique est le troisième.

Ce n’est pas une hypothèse. C’est la réalité quotidienne du développement de produits d’IA en 2026. Des équipes de trois personnes lancent des produits qui auraient nécessité cinquante ingénieurs il y a deux ans, passant de l’idée à la mise sur le marché en quelques jours, et non plus en plusieurs mois.

Mais la rapidité sans vérification est un handicap. L’IA générative a rendu d’une facilité déconcertante, et dangereuse, la mise en production de solutions qui produisent des hallucinations, contredisent vos propres politiques ou fournissent à vos clients des réponses dont l’inexactitude peut être démontrée. C’est dans l’écart entre « nous avons mis en production » et « nous avons mis en production quelque chose de fiable » que les start-ups échouent.

La cause racine est d’ordre structurel. Les grands modèles linguistiques sont des systèmes stochastiques. Ils génèrent du texte en prédisant le prochain jeton probable. Ce processus intègre une part d’aléatoire de par sa conception : la température, les stratégies d’échantillonnage et les paramètres top-k/top-p introduisent tous une variabilité. Une même requête peut produire des réponses différentes selon les exécutions. C’est ce qui rend les grands modèles linguistiques créatifs et utiles. C’est également ce qui les rend fondamentalement peu fiables pour les tâches exigeant une exactitude. Votre modèle ne cherchait pas à donner de mauvais conseils en matière de crédit immobilier. Il prédisait simplement le jeton suivant le plus probable.

Toute start-up spécialisée dans l’IA doit résoudre ce dilemme : comment s’appuyer sur des systèmes probabilistes tout en offrant des garanties d’exactitude à ses clients, aux autorités de régulation et à ses investisseurs ?

Que se passe-t-il lorsque l’IA donne la mauvaise réponse ?

Lorsque votre IA fournit des conseils erronés et qu’un client les suit, vous êtes responsable du résultat. Si votre IA dédiée à la santé communique une décision de prise en charge erronée lors de quelques centaines d’interactions avec des patients, les sanctions civiles prévues par la loi HIPAA vont de 137 à 68 928 USD par infraction, en fonction du niveau de gravité, avec des plafonds annuels pouvant atteindre 2 067 813 USD par catégorie d’infraction, selon les derniers chiffres ajustés en fonction de l’inflation. Ces amendes peuvent dépasser le montant total de votre financement avant même que vous ne vous rendiez compte qu’il y a un problème. En vertu du RGPD, les amendes pour infractions graves peuvent atteindre 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu. Pour une start-up en phase de démarrage traitant des données de clients de l’UE, il ne s’agit pas d’une simple amende. C’est la fin de l’activité. Un chatbot fintech qui accorde un prêt à une personne non éligible engendre une responsabilité réglementaire. Un bot d’assurance qui présente de manière erronée les conditions de couverture crée un litige contractuel que vous ne pouvez pas gagner.

Au-delà des sanctions directes, il existe des coûts indirects : l’accord commercial qui tombe à l’eau parce que vous ne parvenez pas à passer leur contrôle de sécurité, l’audit SOC 2 qui s’enlise parce que vous ne pouvez pas expliquer comment votre IA prend ses décisions, l’investisseur de série A qui demande « que se passe-t-il lorsque votre IA se trompe ? » et n’obtient pas de réponse satisfaisante.

Pourquoi une ingénierie de requête et un RAG ne suffisent pas

Toutes les start-ups qui développent des LLM s’appuient sur une structure de sécurité similaire : une ingénierie de requête minutieuse, la génération augmentée par la recherche (RAG) et un certain niveau de vérification manuelle. Ce sont là de bonnes pratiques. Mais elles ne suffisent pas.

L’ingénierie de requête repose sur une approche heuristique, et non sur des principes démontrables. Vous élaborez des instructions destinées à orienter le modèle vers un comportement correct, mais rien ne garantit que celui-ci les suivra. Lorsque vous passez à une version plus récente du modèle ou que vous modifiez l’invite de votre système pour gérer un nouveau cas limite, un comportement auparavant sûr peut cesser de fonctionner sans que vous vous en rendiez compte. Vous fondez la sécurité sur des contrats informels dépourvus de tout mécanisme d’application.

Le RAG réduit la probabilité d’hallucinations en ancrant le modèle dans les documents extraits. Il s’agit là d’une réelle amélioration. Cependant, le modèle peut toujours ignorer, mal interpréter ou utiliser de manière sélective le contexte extrait. Le RAG fait pencher la distribution de probabilité vers de meilleures réponses. Il n’élimine pas pour autant la possibilité de réponses erronées. « Généralement correct » ne constitue pas une stratégie de conformité.

Le contrôle qualité manuel ne s’adapte pas à votre croissance. Même un échantillonnage intensif (vérification de 10 % des interactions) laisse 90 % des interactions non vérifiées. Pour une start-up traitant 100 000 interactions clients par mois, embaucher des vérificateurs pour contrôler par échantillonnage les résultats coûte des centaines de milliers de dollars par an. C’est un effectif dont vous ne disposez pas au stade de démarrage, et vous continuez à fonctionner à l’aveuglette pour les 90 % que vous n’avez pas vérifiés. Cette dépense n’est pas ponctuelle. La manière dont vos clients formulent leurs questions évolue au fil du temps. Les modèles eux-mêmes changent sans que vous vous en rendiez compte. Des comportements auparavant fiables peuvent se dégrader après une mise à jour de routine du modèle. Une invite soigneusement rédigée qui fonctionnait le mois dernier peut échouer sans crier gare le mois suivant. Vous devez continuellement évaluer, retester et adapter votre processus d’assurance qualité, ce qui en fait un centre de coûts permanent plutôt qu’un problème que vous résolvez une fois pour toutes.

Le point commun à toutes ces approches est qu’elles réduisent le risque sans pour autant offrir de certitude. Lorsque votre investisseur vous demande : « Votre IA peut-elle produire des résultats erronés ? », la réponse honnête, si l’on se base uniquement sur ces outils, est : « Probablement pas, la plupart du temps. » Ce n’est pas le genre de réponse qui permet de conclure un tour de table de série A, ni qui satisfait un organisme de régulation.

Qu’est-ce que le raisonnement automatisé ?

Le raisonnement automatisé est un domaine de l’informatique qui utilise la logique mathématique pour garantir ce qu’un système fera ou ne fera pas. Contrairement au machine learning, qui tire des modèles à partir de données, le raisonnement automatisé recourt à la logique mathématique, à la démonstration de théorèmes et à la résolution de contraintes pour prouver que certaines propriétés spécifiques sont valables dans l’espace infini de toutes les entrées possibles.

Cette distinction est fondamentale. Lorsqu’un modèle de machine learning affirme que « ce résultat a 95 % de chances d’être correct », il s’agit d’une affirmation statistique. Lorsqu’un système de raisonnement automatisé affirme que « ce résultat est valide », cela signifie qu’il a établi une preuve mathématique démontrant que ce résultat satisfait à toutes les contraintes que vous avez définies. Il n’y a pas d’intervalle de confiance. Soit la preuve existe, soit elle n’existe pas.

Le raisonnement automatisé ne remplace pas les grands modèles de langage (LLM). Votre chatbot a toujours besoin d’un modèle linguistique pour comprendre les questions des clients et générer des réponses naturelles. Le raisonnement automatisé apporte une couche de vérification supplémentaire : les LLM génèrent, le raisonnement automatisé vérifie.

Ensemble, ils constituent une solution complète où créativité et exactitude vont de pair. Votre IA peut tout à fait rester conversationnelle, utile et rapide. Mais le raisonnement automatisé garantit qu’elle respecte les contraintes métier et de conformité que vous définissez.

Comment AWS utilise le raisonnement automatisé

AWS utilise depuis des années le raisonnement automatisé en environnement de production pour protéger l’infrastructure sur laquelle s’appuient les start-ups (et tous les autres utilisateurs).

• Zelkova, le moteur de raisonnement automatisé qui sous-tend l’analyseur d’accès AWS IAM, utilise la résolution par satisfiabilité modulo théories (SMT) pour vérifier mathématiquement que vos politiques IAM et Amazon Simple Storage Service (Amazon S3) fonctionnent exactement comme prévu, en détectant ainsi des chemins d’accès imprévus qui échappent à une vérification manuelle.
• Cedar, qui fait désormais partie des projets d’environnement de test (sandbox) de la CNCF, est le premier langage de politiques d’autorisation conçu dès le départ pour être vérifié à l’aide du raisonnement automatisé ; il est à la base d’Amazon Verified Permissions.
• Le Nitro Isolation Engine, premier hyperviseur cloud ayant fait l’objet d’une vérification formelle, garantit l’isolation des locataires sur Amazon Elastic Compute Cloud (Amazon EC2) grâce à environ 260 000 lignes de preuves vérifiées par ordinateur.
• s2n-tls, la bibliothèque TLS open source d’AWS, utilise des preuves formelles pour vérifier que ses opérations cryptographiques résistent aux attaques par canal latéral temporel

Le point essentiel pour les créateurs de start-ups est le suivant : les techniques de vérification mathématique mises à votre disposition via Amazon Bedrock et Amazon Bedrock AgentCore ne sont pas des prototypes de recherche. Elles proviennent de la même discipline d’ingénierie qu’AWS utilise pour garantir la durabilité de S3, l’isolation d’EC2 et la sécurité de chaque connexion TLS vers les services AWS. Jusqu’à récemment, pour accéder à cette discipline, il fallait constituer une équipe interne composée de docteurs spécialisés dans les méthodes formelles, un luxe réservé aux organisations disposant de budgets de recherche. Bedrock et AgentCore en font désormais un simple appel d’API facturé à l’utilisation.

Comment les start-ups peuvent-elles utiliser le raisonnement automatisé ?

Pour les équipes de start-up, cette même rigueur de vérification mathématique est désormais directement accessible grâce à deux produits, chacun traitant une couche différente du problème de confiance en l’IA.

Les vérifications du raisonnement automatisé des barrières de protection Amazon Bedrock utilisent une logique formelle basée sur la SMT (la même approche que celle de Zelkova) pour vérifier que le contenu généré par votre LLM respecte vos règles métier. Vous commencez par définir vos politiques : critères d’octroi de crédit, protocoles de soins de santé, règles de conformité, ou tout autre élément requis par votre activité. Le système les traduit ensuite en logique formelle et vérifie chaque réponse du LLM par rapport à ces règles. Lorsque le modèle émet une déclaration qui contredit votre politique, le système le détecte et vous indique précisément quelle règle a été enfreinte et pourquoi.

Dans le cas du scénario de prêt immobilier présenté au début de cet article, le système aurait détecté l’erreur concernant l’apport initial de 8 % et aurait proposé la valeur correcte au LLM afin qu’il reformule la réponse avant même que celle-ci ne parvienne à l’utilisateur.

La Policy dans Amazon Bedrock AgentCore utilise Cedar (un langage open source dédié aux politiques d’autorisation) pour imposer des limites déterministes aux actions des agents d’IA. Si vous développez des applications basées sur des agents dans lesquelles votre IA prend des décisions critiques en invoquant des outils, qu’il s’agisse d’accéder à des données sensibles, d’écrire dans des systèmes externes ou d’effectuer des actions pour le compte des utilisateurs, Policy intercepte chaque requête de l’agent vers un outil au niveau de la passerelle et l’évalue au regard des politiques Cedar avant son exécution. Cette application est déterministe. Elle fonctionne indépendamment du raisonnement de l’agent et ne peut être contournée par l’injection d’invite, des hallucinations ou des bogues dans le code de votre agent. Pour une start-up du secteur de la santé, de la fintech ou du droit, cela signifie que vous pouvez indiquer précisément à votre autorité de régulation ce que votre agent peut et ne peut pas faire, en vous appuyant sur une politique validée mathématiquement.

Les autres systèmes du portefeuille de méthodes formelles d’AWS (Nitro Isolation Engine, s2n-tls, s2n-quic, Dafny) vous apportent des avantages indirects : chaque instance EC2 que vous exécutez repose sur un mécanisme d’isolation vérifié formellement, et chaque connexion TLS utilise une cryptographie vérifiée formellement. C’est au niveau des barrières de protection Bedrock et de Policy dans AgentCore que les méthodes formelles s’intègrent directement dans le code de votre application.

Deux couches, un seul principe : la vérification mathématique formelle fondée sur la confiance stochastique.

Ce que cette série couvre ensuite

Il s’agit de la première partie d’une série en trois volets. Dans la deuxième partie, intitulée Logique formelle, politiques Cedar et aspects économiques de la vérification, nous allons dans les détails : comment fonctionnent les politiques de raisonnement automatisé, comment vos règles métier se traduisent en logique formelle, à quoi ressemble le pipeline de vérification, et quels sont les aspects économiques de la vérification mathématique par rapport aux équipes d’assurance qualité manuelle. Dans la troisième partie, intitulée Guide de mise en œuvre étape par étape, nous vous proposons un guide pratique comprenant des modèles de code prêts à l’emploi pour intégrer les contrôles AR des barrières de protection Bedrock et Policy dans AgentCore à votre infrastructure.