Développement Oracle : quand le modèle a besoin de données vérifiées

La première fois qu'un modèle linguistique a renvoyé une réponse erronée avec assurance dans l'un de mes pipelines, le bug ne se trouvait pas dans le modèle. Il était dans la requête en amont. C'est la leçon que le développement Oracle ne cesse d'enseigner : le modèle hérite de chaque défaut des données qu'il lit, et il les hérite silencieusement. Pas de trace de pile. Pas d'exception. Juste une sortie plausible qui est discrètement fausse.

La contrainte qui rend cela difficile

La plupart des tutoriels sur les produits d'IA traitent la base de données comme un simple conteneur. Les lignes entrent, les lignes sortent, le modèle fait quelque chose d'intéressant au milieu. Cette approche s'effondre dès que la précision est une exigence plutôt qu'une préférence.

En pratique, les flux de travail d'IA qui touchent des données réglementées, des logiques d'éligibilité ou des enregistrements financiers nécessitent les mêmes garanties qu'un système d'entreprise traditionnel : intégrité référentielle, cohérence au niveau des lignes, limites transactionnelles qui tiennent sous des écritures concurrentes. Oracle applique ces garanties au niveau du moteur. C'est pourquoi il apparaît dans les stacks d'entreprise où le coût d'une mauvaise réponse est réel.

La contrainte à laquelle je me heurtais constamment était la suivante : le modèle est un composant d'un flux de travail. Chaque composant en amont doit être correct avant que le modèle n'intervienne. Si l'étape de récupération renvoie des données périmées, ou si une jointure supprime silencieusement des lignes parce qu'une clé étrangère n'a jamais été appliquée, le modèle produit une sortie qui semble faire autorité mais ne l'est pas.

Ce que j'ai réellement construit face à cette contrainte

Sur GritGateway, la plateforme africaine d'intelligence des talents, le problème principal était de faire correspondre les profils de candidats de plus de 25 pays africains à un ensemble de critères d'opportunité qui changeaient fréquemment. La logique de correspondance était assistée par un modèle. Mais les enregistrements des candidats, les définitions des critères et l'historique des correspondances résidaient tous dans un magasin relationnel avec des exigences d'intégrité strictes.

Les requêtes alimentant le modèle devaient renvoyer exactement la bonne population. Une requête trop large signifiait que le modèle classait des candidats non pertinents. Une requête trop étroite signifiait que les candidats qualifiés n'apparaissaient jamais. Aucun de ces modes de défaillance n'était bruyant. Les deux étaient coûteux.

J'ai appliqué trois choses au niveau de la base de données avant qu'un enregistrement n'atteigne le modèle :

• —Le statut du candidat était une colonne contrainte, pas un champ de texte libre. Le modèle n'a jamais vu un statut qu'il n'avait pas été entraîné à interpréter.
• —L'historique des correspondances était écrit dans une transaction qui mettait également à jour l'enregistrement du candidat. Pas d'écritures partielles. Soit les deux étaient validées, soit aucune ne l'était.
• —Les requêtes de récupération étaient paramétrées et examinées pour leur stabilité de plan. Une requête rapide sur un petit ensemble de données et lente sur un grand introduirait des pics de latence qui perturberaient l'étape d'approbation humaine en aval.

Ce dernier point est plus important qu'il n'y paraît. Lorsqu'un réviseur humain est impliqué, la latence n'est pas seulement un chiffre de performance. C'est ce qui détermine si le réviseur lit réellement la sortie ou la parcourt rapidement.

L'approbation humaine modifie le modèle de données

La plupart des schémas de base de données sont conçus autour des écritures : un utilisateur fait quelque chose, vous l'enregistrez. Les flux de travail d'IA qui incluent une étape d'approbation humaine nécessitent une forme différente. Vous devez enregistrer ce que le modèle a proposé, ce que le réviseur a vu, ce qu'il a décidé, et quand. Cela représente quatre états, pas deux.

Sur OptimalTax, le système automatisé de déclaration fiscale, la table d'état d'approbation était la table la plus importante du schéma. Le système a atteint une précision de calcul fiscal de 99%, mais ce chiffre n'avait de sens que parce que chaque calcul avait un enregistrement d'approbation correspondant. Les auditeurs pouvaient reconstituer le chemin de décision complet. La sortie du modèle était stockée séparément de la sortie confirmée. Elles n'étaient jamais dans la même colonne.

C'est une décision de schéma, pas une décision de modèle. Elle doit être prise avant d'écrire la première requête.

Le virage SLM et ce que cela signifie pour la couche de données

En 2026, davantage d'équipes déploient des modèles linguistiques de petite taille (SLM) affinés de moins de dix milliards de paramètres pour des cas d'utilisation sensibles à la latence et hors ligne. Les modèles plus petits sont plus rapides et moins chers à exécuter. Ils sont également plus sensibles à la qualité des données, car ils ont moins de connaissances générales sur lesquelles s'appuyer lorsque l'entrée est ambiguë ou mal formée.

Un grand modèle pourrait se remettre gracieusement d'une entrée mal structurée. Un SLM affiné et entraîné sur un domaine étroit ne le fera pas. Cela augmente les enjeux pour la couche de récupération et de transformation. La base de données doit faire plus de travail : normaliser les valeurs, appliquer les types énumérés, rejeter les valeurs nulles qui auraient auparavant été gérées en aval.

En pratique, cela signifie que le schéma de la base de données fait partie du contrat d'exploitation du modèle. Si vous modifiez un type de colonne ou assouplissez une contrainte, vous modifiez les entrées sur lesquelles le modèle a été affiné. C'est un changement majeur, même si la couche applicative ne le remarque jamais.

La vérification par rapport aux sources est une décision d'architecture

Sur Fursa, le moteur d'éligibilité aux itinéraires de visa couvrant plus de 170 pays de destination, l'exigence fondamentale était que chaque résultat d'éligibilité devait être traçable à un enregistrement source. Le modèle ne pouvait pas inventer un itinéraire. Il ne pouvait que confirmer ou refuser en fonction de ce qui se trouvait dans la base de données.

Cela semble évident. Ce n'est pas facile à mettre en œuvre. La tentation est de laisser le modèle combler les lacunes, car il les comble généralement de manière plausible. La discipline consiste à traiter une lacune comme une inconnue explicite et à la faire apparaître comme telle, plutôt que de laisser le modèle la masquer.

L'architecture qui a soutenu cela comportait une table de sources vérifiées avec un horodatage de dernière confirmation sur chaque enregistrement. Les requêtes vers la couche modèle effectuaient des jointures avec cette table et excluaient les enregistrements plus anciens qu'un seuil défini. Les données périmées n'atteignaient pas le modèle. Elles étaient plutôt signalées pour examen.

Cette jointure a ajouté de la latence. Cela en valait la peine. Un demandeur de visa agissant sur un résultat d'éligibilité périmé fait face à de réelles conséquences. Le coût de la latence était un choix de conception, pas une négligence.

Ce que cela signifie du point de vue de l'ingénierie

Si vous êtes un CTO ou un responsable de l'ingénierie évaluant si un produit d'IA est conçu pour tenir la route, la couche de base de données est l'endroit où je commencerais. Pas le modèle. Pas le prompt. Les données.

Plus précisément, je demanderais :

• —Les écritures sont-elles transactionnelles lorsque la sortie du modèle dépend d'un état cohérent ?
• —L'état d'approbation ou de révision est-il modélisé explicitement, ou est-il déduit de la logique applicative ?
• —Les requêtes de récupération sont-elles examinées pour leur stabilité de plan sous des volumes de données de production ?
• —Existe-t-il un mécanisme pour exclure les enregistrements périmés ou non vérifiés de l'ensemble d'entrée du modèle ?

Ce ne sont pas des questions nouvelles. Ce sont des questions de données d'entreprise standard appliquées à un contexte où les conséquences de les mal gérer sont moins visibles qu'un bug traditionnel.

La perspective d'ingénierie approfondit l'architecture, les choix de stack et les compromis que j'ai faits sur ces projets. Si vous souhaitez voir le dossier complet, les études de cas montrent ce que chaque système a été conçu pour faire et la contrainte autour de laquelle il a été construit.

Si vous élaborez un produit d'IA qui nécessite ce type de rigueur, le formulaire de contact est le bon point de départ. Apportez la contrainte. C'est là que le travail commence.