Sous le capot d'Oupi : quatre briques expliquées

Sous le capot de Oupi : quatre briques que l'on ne voit jamais

La conversation publique sur l'intelligence artificielle est presque entièrement occupée par les modèles. Leur taille, leurs scores aux évaluations, la baisse de leur prix au million de jetons. Ce sont des indicateurs utiles, mais ils masquent une réalité que tout praticien finit par rencontrer : un modèle, aussi performant soit-il, ne constitue pas un produit. Entre la requête d'un utilisateur et une réponse fiable, exploitable et sûre, il existe une couche d'ingénierie dont on parle rarement, et qui détermine pourtant l'essentiel de la valeur réellement livrée.

Cet article décrit quatre composants de Oupi qui appartiennent à cette couche. Aucun n'est un modèle de langage. Chacun résout un problème que les modèles, laissés seuls, ne résolvent pas.

1. L'orchestration : choisir le bon modèle, pas le plus puissant

La première décision prise par Oupi n'est pas comment répondre, mais avec quoi répondre. À la réception d'une requête, un mécanisme d'aiguillage en analyse l'intention, la complexité et le domaine, puis sélectionne le modèle le mieux adapté parmi la soixantaine disponibles.

Ce choix a une conséquence directe sur les coûts. Le prix d'une tâche dépend du modèle mobilisé, et l'écart entre un modèle léger et un modèle de pointe se compte en ordres de grandeur. Confier une reformulation d'e-mail ou une classification simple à un modèle de raisonnement avancé revient à mobiliser une ressource coûteuse pour une opération triviale. À l'échelle d'une organisation qui traite des milliers de requêtes par jour, l'accumulation de ces surdimensionnements pèse lourdement sur la facture — et sur la consommation énergétique.

L'orchestration inverse cette logique. Elle affecte à chaque tâche un modèle ni sous-dimensionné, ni surdimensionné, ce qui maximise le volume d'usage possible pour un budget de crédits donné. L'utilisateur n'a pas à connaître les forces et faiblesses de chaque modèle : cette expertise est déléguée à la plateforme.

Cette approche a une seconde vertu, moins immédiate. En rendant Oupi agnostique du fournisseur, elle protège l'organisation d'une dépendance à un acteur unique. Lorsqu'un nouveau modèle plus performant ou moins coûteux apparaît, il est intégré au dispositif d'aiguillage sans que l'utilisateur ait à changer quoi que ce soit à ses usages. La valeur ne réside pas dans un modèle en particulier, mais dans la capacité à sélectionner le bon au bon moment.

2. Le Trust Layer : rendre le doute visible

Un modèle de langage produit toujours une réponse. Il ne signale jamais spontanément qu'il n'en sait rien. Cette caractéristique est à l'origine du risque le plus insidieux de l'IA générative : l'erreur formulée avec assurance. À mesure que les modèles progressent, leurs formulations gagnent en fluidité, et leurs erreurs deviennent d'autant plus difficiles à repérer.

Demander à un modèle d'évaluer lui-même sa fiabilité n'apporte pas de garantie sérieuse : un système qui se trompe avec conviction s'auto-évalue avec la même conviction. Une mesure crédible doit être externe au modèle qui a produit la réponse.

C'est la fonction du Trust Layer. Cet algorithme attribue en temps réel un niveau de confiance à chaque réponse, en analysant sa cohérence interne et en repérant les affirmations susceptibles d'être fabriquées. Le résultat est présenté à l'utilisateur, non pour disqualifier la réponse, mais pour l'aider à calibrer l'attention qu'il doit lui porter.

Ce choix relève d'une position assumée. Rendre l'incertitude visible peut sembler contre-intuitif pour un produit qui cherche à inspirer confiance. Nous considérons l'inverse : une plateforme qui indique quand se montrer prudent mérite davantage de crédit qu'une plateforme qui affiche la même assurance en toutes circonstances. Lorsque l'IA intervient sur des décisions à enjeu — un contrat, un diagnostic, une recommandation stratégique — savoir quand lui accorder du crédit vaut autant que la réponse elle-même.

3. Le NLQ Engine : la sécurité en amont, non en surcouche

Plus un agent gagne en autonomie et en accès aux outils, plus sa surface d'exposition s'élargit. Un assistant conversationnel isolé présente un risque limité. Un agent capable de lire des documents, d'exécuter du code et d'appeler des services externes constitue une cible d'un tout autre ordre.

L'injection de prompt illustre bien ce risque. Un document soumis à l'analyse peut contenir des instructions dissimulées à destination du modèle — par exemple une consigne d'ignorer ses directives et d'exfiltrer des données. Pour le modèle, ce texte se présente comme n'importe quelle autre entrée. Sans garde-fou, il peut l'interpréter comme un ordre légitime.

Le NLQ Engine constitue le moteur de sécurité natif de Oupi. Il applique neuf couches de validation qui interceptent en amont les tentatives d'injection, les exécutions de code non autorisées et les comportements déviants, avant qu'ils n'atteignent l'utilisateur ou ses données. Le point déterminant est ce positionnement : la validation intervient avant le traitement, et non comme un filtre appliqué après coup. Une sécurité ajoutée en surcouche laisse toujours une fenêtre d'exécution ; une sécurité placée en amont referme cette fenêtre.

Il s'agit d'une réponse architecturale à un paradoxe simple : l'autonomie d'un agent constitue sa principale valeur et, simultanément, sa principale vulnérabilité. On ne peut libérer l'une sans maîtriser l'autre.

4. OupiBox : un atelier isolé et éphémère

Lorsqu'un modèle doit écrire du code, le tester, produire un fichier ou lancer une application, il lui faut un environnement d'exécution réel. Un modèle, à lui seul, n'en dispose pas : il peut décrire une procédure, mais pas l'exécuter.

OupiBox comble cet écart. Chaque tâche d'exécution se voit attribuer un environnement isolé et temporaire, dans lequel le modèle peut travailler concrètement : installer des dépendances, exécuter des scripts, générer des livrables. Une fois la tâche accomplie, le conteneur est détruit, sans laisser de trace sur les systèmes de l'utilisateur.

Deux propriétés méritent d'être soulignées. L'isolement garantit qu'un code exécuté n'a aucun accès aux systèmes de l'organisation : il opère dans un espace clos, sans passerelle vers l'extérieur. Le caractère éphémère assure qu'aucun état ne persiste d'une exécution à l'autre, ce qui écarte les effets de bord et les contaminations entre tâches.

Cette capacité prolonge naturellement l'orchestration décrite plus haut. Un modèle, aussi avancé soit-il, ne se fournit pas à lui-même un environnement d'exécution de qualité. OupiBox met cette capacité à la disposition de l'ensemble des modèles, indépendamment de leur fournisseur : la plateforme apporte ce que le modèle ne peut apporter seul.

Ce que l'on retient

Ces quatre composants ont un point commun : aucun ne cherche à concurrencer les modèles. Ils les entourent. L'orchestration décide lequel mobiliser, le Trust Layer évalue ce qu'ils produisent, le NLQ Engine protège leurs interactions, OupiBox leur donne les moyens d'agir.

La qualité d'un système d'IA ne se réduit pas à la performance du modèle qu'il embarque. Elle tient à la solidité de l'infrastructure qui décide, vérifie, protège et exécute autour de lui. C'est cette infrastructure qui distingue une démonstration prometteuse d'un outil réellement utilisable au quotidien — et c'est précisément là que se concentre notre travail.