La dernière enquête sur l’IA, Pulse Survey d’EY, indique que 87 % des cadres dirigeants font état de difficultés d’adoption, allant des problèmes de cybersécurité et de données à l’absence de politiques et de gouvernance. L’intégration de l’intelligence artificielle générative (IA générative) dans l’entreprise nécessite à la fois la volonté et la capacité de la concrétiser. Entre les deux se dressent la complexité opérationnelle et la nécessité d’instaurer la confiance dans cette nouvelle technologie.
Les entreprises développent et déploient des logiciels depuis des décennies, mais l’IA générative pose un nouveau défi : celui du contrôle. Contrairement aux logiciels traditionnels, les applications d’IA générative disposent d’une certaine autonomie et sont non déterministes. Il est donc impossible de garantir qu’elles feront uniquement ce qui était prévu, sans jamais produire de résultats indésirables — du moins, pas encore. Ce manque de contrôle freine leur adoption à grande échelle. Pour mieux appréhender ce défi, il convient d’examiner le pouvoir du contexte. Cette compréhension permettra aux entreprises de faire évoluer les principes traditionnels de conception logicielle afin de les adapter à l’IA générative.
Avec suffisamment de contexte, l’incertitude liée aux applications d’IA générative devient maîtrisable, car le contexte comble l’écart entre ce que ces applications peuvent faire et les objectifs de l’entreprise. Le contexte peut provenir de trois domaines : l’application d’IA générative, l’environnement et l’entreprise.
Comparaison du contexte applicatif
Le contexte disponible au sein des applications d’IA générative diffère considérablement de celui des applications traditionnelles. Les applications traditionnelles déterminent à l’avance les entrées autorisées en tant que paramètres d’opérations prédéfinies. Les mêmes entrées produiront toujours les mêmes résultats. À l’inverse, les applications d’IA générative acceptent un éventail beaucoup plus large d’entrées dans les grands modèles de langage (LLM), dont les résultats sont, par conception, non déterministes. Les mêmes entrées peuvent donc produire ou non les mêmes résultats.
Exemple de déterminisme d’une application traditionnelle :
Cet exemple en Python calcule l’âge d’une personne à partir de sa date de naissance et de la date actuelle. Par souci de concision, il n’inclut pas certains raffinements, tels que la gestion des types et la prise en compte des anniversaires déjà passés dans l’année en cours.
from datetime import datetime
from typing import Union
def calculate_age(birthdate:str, current_date:str) -> int
age = current_dt.year - birth_dt.year
return age
Données : date de naissance = 30 juin 1972 et date actuelle = 31 août 2025
Âge = 53 ans.
Exemple de non-déterminisme d’une application d’IA générative :
Cette application peut estimer l’âge probable d’une personne à partir d’informations plus générales, sans avoir à connaître sa date de naissance ni la date actuelle.
Les applications d’IA générative acceptent une grande variété d’entrées pour l’inférence des LLM.
Invite : Quel âge a une personne qui aime le disco et se souvient de l’athlète qui a remporté la médaille d’or olympique du 100 m féminin à Barcelone ?
Après avoir soumis exactement ce prompt au LLM à trois reprises, les réponses obtenues ont été les suivantes :
Réponse 1 : 55 ans
Réponse 2 : 40 à 60 ans
Réponse 3 : la quarantaine, la cinquantaine ou la soixantaine
La fonction Python intégrée à l’application traditionnelle accepte deux entrées (la date de naissance et la date actuelle) et calcule la différence en années. Elle ne peut pas déduire l’âge d’une personne ni accepter des descriptions de ses préférences, de ses habitudes, etc., car elle n’est pas capable de synthétiser des informations ni d’en tirer des conclusions.
En comparaison, l’application d’IA générative peut s’appuyer sur des indications concernant les genres musicaux populaires durant l’enfance et sur des connaissances générales relatives aux grands événements sportifs pour formuler une réponse. Toutefois, les réponses peuvent varier, car de légères différences dans les données d’entrée, notamment la reformulation d’une question ou les paramètres de température (qui influent sur le degré d’aléatoire des réponses des LLM), peuvent entraîner des résultats différents. Même si le code de l’application reste inchangé d’une réponse à l’autre, les réponses peuvent différer. Cette variabilité augmente avec la complexité du prompt, l’ajout de sources de données supplémentaires et le comportement des composants de routage au sein de l’infrastructure d’inférence.
Compte tenu de cette marge de manœuvre, il est facile d’imaginer des situations dans lesquelles une application d’IA générative pourrait s’écarter considérablement de son comportement prévu en l’absence de contexte supplémentaire. Ces deux exemples illustrent le déterminisme extrême des logiciels traditionnels et le non-déterminisme des applications d’IA générative. On ne s’attendrait pas à ce qu’un logiciel traditionnel devine ou prédise l’âge d’une personne à partir du contexte, alors que les applications d’IA générative sont couramment censées traiter ce type de questions non déterministes. Si l’application ne dispose pas d’un contexte suffisant, il faut alors examiner son environnement.
Le contexte environnemental fournit à l’application des informations provenant de l’extérieur
L’environnement se compose de l’infrastructure et des services qui entourent l’application. En juillet 1982, lors du séminaire CreativeThink consacré à l’industrie informatique, Alan Kay a déclaré : « Les personnes qui prennent vraiment les logiciels au sérieux devraient fabriquer leur propre matériel », tant il était convaincu du lien étroit entre les deux. J’aimerais étendre cette idée à l’environnement de déploiement.
Les applications ne fonctionnent pas en vase clos. Toutes sortes de services d’infrastructure se combinent pour leur fournir un environnement d’exécution. Bien qu’externes aux applications, ces services sont tout aussi essentiels à leur bon fonctionnement que le matériel. En poussant ce raisonnement un peu plus loin, ces services d’infrastructure font l’objet d’une surveillance rigoureuse au moyen de diverses solutions d’observabilité qui recueillent et suivent au fil du temps de riches données de télémétrie. Ces données décrivent les performances de l’application et la manière dont l’environnement qui l’entoure peut l’affecter.
Le contexte environnemental peut être divisé en deux catégories : passif et actif. Toutes les formes de télémétrie (par exemple, les journaux, les métriques, les traces et les événements) peuvent être considérées comme passives, car elles sont émises et collectées en continu pendant le fonctionnement de l’infrastructure et des applications. Les alertes, les notifications et les tableaux de bord sont actifs. Ils s’appuient sur des règles pour interpréter les données de télémétrie et communiquer le contexte opérationnel. Le paramétrage de ces règles donne un sens opérationnel aux informations en déterminant à quel moment les seuils de tolérance sont sur le point d’être atteints ou sont dépassés, où que ce soit dans l’environnement.
Les applications d’IA générative remettent en question l’approche fondée sur des règles, car il n’existe pas encore de télémétrie fiable permettant de couvrir les comportements potentiels, apparemment infinis, d’un composant autonome. Cela ne signifie pas pour autant qu’aucune innovation n’a lieu. Deux approches sont actuellement expérimentées : les métriques propres à un domaine pour mesurer la réussite de l’IA générative et le « LLM-as-a-Judge ». La première recourt à d’autres moyens pour établir une vérité de référence, puis la comparer au résultat produit par une IA générative, afin de comptabiliser les taux de réussite et d’échec. La seconde utilise un LLM pour évaluer la précision d’un autre. Seul l’avenir dira dans quelle mesure ces approches divergentes permettront de parvenir à un véritable contrôle de l’IA générative grâce au contexte environnemental.
L’intention métier complète la vision du contexte
L’intention métier se définit par la formule : « Tout ce que l’entreprise souhaite, et rien de ce qu’elle ne souhaite pas. » Elle couvre les situations susceptibles d’échapper à l’application et à l’environnement.
L’actualité récente met en lumière un cas où le composant d’IA générative d’une application s’est vu accorder des pouvoirs suffisants pour effectuer des opérations extrêmement préjudiciables, telles que la suppression de tous les enregistrements clients d’une base de données. Voici quelques éléments factuels tirés de cette situation qui illustrent l’écart entre les intentions de l’entreprise et les actions que les applications d’IA générative sont susceptibles d’effectuer.
| Ce qui s’est passé | Le contexte métier manquant |
|---|---|
| L’outil de programmation basé sur l’IA a supprimé une base de données de production pendant une période de gel du code. |
|
| L’outil de programmation basé sur l’IA a indiqué que les restaurations de bases de données n’étaient pas prises en charge et qu’aucune instance n’était disponible pour effectuer une restauration. Pourtant, l’exécution manuelle d’une restauration a bel et bien fonctionné. |
|
Cette étude de cas illustre quelques-uns des nombreux écarts potentiels entre ce que l’IA générative peut être autorisée à faire et ce qu’une entreprise souhaite qu’elle fasse.
Concevoir une application dotée d’une fonction permettant de supprimer un enregistrement est tout à fait raisonnable, mais autoriser l’IA à supprimer tous les enregistrements sans demander la permission ne l’est pas. Dans les logiciels traditionnels, l’autorisation de supprimer des enregistrements est restreinte afin de réduire le risque de pertes pour l’entreprise. Toutefois, l’IA générative introduit une autonomie qui n’est pas suffisamment encadrée par les contrôles d’accès fondés sur les rôles. Le contexte métier permet ici de définir les comportements attendus et inattendus, puis de les traduire en exigences précises, notamment en actions explicitement interdites et en interruptions obligatoires nécessitant une intervention humaine. C’est la prise en compte de l’ensemble du contexte qui permet d’atteindre ce niveau de contrôle.
Les architectures applicatives conçues avant l’arrivée de l’IA générative sont tout simplement insuffisantes. L’essor de l’IA générative exige un nouveau modèle architectural qui réunit les trois domaines de contexte : l’application, son environnement et l’intention métier. Cette explication de Phil Schmid, ingénieur senior en relations avec l’IA chez Google DeepMind, est particulièrement utile pour comprendre la différence fondamentale qu’introduisent les applications d’IA générative. Elle souligne que les LLM reçoivent le contexte dans leurs données d’entrée et montre comment les différents composants d’une application d’IA générative définissent et utilisent chacun le contexte à leur manière.
L’architecture et l’ingénierie des applications d’IA générative doivent exploiter les trois domaines de contexte afin de produire des résultats systématiquement conformes aux objectifs métier. Sans une vision globale du contexte, le contrôle n’est qu’une illusion, la confiance est inexistante et l’adoption à grande échelle reste hors de portée.
À propos de l’auteur
Articles de blog associés
Contrôler les applications d’IA générative grâce au contexte
Maîtriser les applications d’IA générative implique de tirer parti du contexte applicatif, environnemental et métier. Découvrez pourquoi une vision complète du contexte est essentielle pour garantir la confiance et favoriser l’adoption.