Comment l'ingénierie des données agentique change notre façon de construire – et ce qu'une entreprise de santé a appris en le mettant en pratique
par Navdeep Alam et Zhe Sun
Vous connaissez cette sensation. Votre équipe a une excellente idée de pipeline alimenté par l'IA – peut-être un nouveau produit de données, ou un agent qui automatise un flux de travail que personne ne veut faire manuellement. Le sponsor exécutif est enthousiaste. Le responsable de l'ingénierie esquisse une architecture sur un tableau blanc. Et puis… les semaines passent. Les environnements doivent être provisionnés. Le contexte se perd entre les équipes. Le temps que le prototype soit prêt, le sponsor exécutif est passé à autre chose, l'équipe a perdu son élan et l'initiative s'éteint discrètement derrière un projet plus récent.
Ce fossé, entre le « essayons ceci » et un prototype fonctionnel, est ce que nous appelons la taxe de prototypage. Et elle détruit plus de feuilles de route IA que n'importe quelle limitation de modèle ne le fera jamais.
Le goulot d'étranglement ne réside pas dans la vitesse à laquelle vos ingénieurs écrivent du code, mais dans l'efficacité de la R&D de l'organisation dans son ensemble. La R&D traditionnelle est conçue pour être pilotée par des humains : elle a rendu possible le développement de logiciels à grande échelle, mais elle n'a pas été conçue pour les agents IA. Trois forces viennent alourdir cette taxe :
Ces frictions expliquent un constat récurrent chez les développeurs : les agents IA semblent révolutionnaires sur des projets personnels, mais décevants sur des bases de code en production. L'agent n'est pas devenu plus bête. C'est simplement que la base de code n'a pas été conçue pour qu'il puisse s'y retrouver.
C'est cela, la taxe de prototypage. La plupart des feuilles de route IA que nous avons vues en paient une forme ou une autre. Les équipes qui prennent de l'avance sont celles qui ont trouvé le moyen d'arrêter de la payer.
Les équipes qui prennent de l'avance n'utilisent pas de meilleurs agents. Elles leur offrent un meilleur point de départ : un point ancré dans la sémantique métier, et pas seulement dans la syntaxe. Lorsque l'agent dispose déjà de ce contexte, deux aspects de votre façon de construire changent.
L'intention devient la spécification. Une description claire de ce que vous voulez suffit pour commencer, et l'ancienne couche de traduction – où les humains transformaient l'intention en exigences techniques avant que quiconque ne puisse coder – fusionne directement avec la session de développement. La gouvernance s'intègre au processus : le lignage, les contrôles d'accès et les contraintes de conformité sont actifs pendant la création, et non découverts après coup quand quelqu'un demande : « Attendez, peut-on vraiment utiliser ces données ? »
Rien de tout cela ne change la responsabilité du résultat. Cela change simplement la forme que prend cette responsabilité. Le développeur passe du rôle d'auteur à celui d'architecte, de réviseur et de guide : moins de temps passé à coder, plus de temps à décider. L'agent est un multiplicateur de jugement, pas un substitut.
Voici l'inversion fondamentale : dans le développement traditionnel, vous vous alignez avant de construire. Vous rédigez une spécification, diffusez un document de conception, organisez une réunion sur les exigences – et tout cela n'est qu'une simulation de la réalité. Ensuite, vous implémentez, vous vous heurtez à un imprévu, vous redéfinissez le périmètre, vous réimplémentez. Les semaines passent.
Dans le développement agentique, l'alignement se fait par la construction. Vous formulez vos hypothèses, l'agent conçoit un MVP fonctionnel en quelques heures, et la spécification émerge du code opérationnel, et non l'inverse. Le document de conception devient exact par construction, car il découle de la réalité et non de l'imagination.
Compressez l'amont, maintenez l'aval. Le parcours de mise en production ne change pas : même CI/CD, même revue de code, même rigueur. Pas de voie rapide pour le code généré par IA. Ce qui change, c'est que les prototypes atteignent la phase de consolidation et de déploiement avant que l'élan ne s'essouffle.
Trois indicateurs vous permettent de savoir si la taxe de prototypage diminue réellement, ou si vous avez simplement fait un bon atelier de travail.
Ce qu'il mesure | Indicateur | Pourquoi c'est important |
Vitesse de compression | Délai de prototypage – de l'idée au MVP présentable | Indicateur avancé. Si ce délai ne diminue pas, la boucle ne fonctionne pas. |
Qualité de la compression | Taux d'acceptation au premier passage – % de critères d'acceptation remplis sans cycle de retouche | Prouve que l'agent a construit la bonne solution, et pas seulement une solution rapide. |
Durabilité du résultat | Taux de passage du PoC à la production – % déployé via CI/CD sous 90 jours | Indicateur retardé. Prouve que les prototypes ne sont pas de simples démos sans lendemain. |
Suivez ces trois indicateurs par équipe, établissez une référence dès maintenant et observez la tendance sur un trimestre. Si le délai de prototypage diminue mais que le taux de passage du PoC à la production ne suit pas, vous générez des démos, vous ne livrez pas de produits.
Les agents de codage généraux sont très performants pour la syntaxe, les fichiers et les API. Ce qu'ils ne connaissent pas, c'est votre activité : vos schémas et leur signification, votre modèle de gouvernance, vos schémas de déploiement. Ils partent donc à la recherche d'informations, une tentative après l'autre, consommant des jetons et du temps pour reconstruire un contexte que la plateforme possède déjà.
Nous disposons de chiffres sur le coût de cette recherche d'informations. Sur un benchmark de 401 tâches de données réelles, un agent de données natif de la plateforme a atteint une précision de 77 % contre 56 à 72 % pour les principaux agents de codage généraux, pour environ la moitié du coût par tâche. Le compromis qualité-coût auquel on pourrait s'attendre n'existait tout simplement pas. L'expertise se traduit simultanément par de la précision, de la rapidité et une réduction des coûts.
Sur Databricks, cela se traduit par Genie Code – un agent de données autonome intégré directement à Unity Catalog – associé à Genie Ontology, une couche sémantique gouvernée qui donne à l'agent une compréhension métier, et pas seulement des noms de colonnes. L'agent lit la signification d'une table plutôt que de la deviner, et hérite par défaut de vos contrôles d'accès et de votre gouvernance.
Le point de départ n'a jamais autant d'importance que dans les secteurs réglementés. Lorsque les données sont sensibles et que la gouvernance n'est pas négociable, l'approche « explorer et deviner » d'un agent de codage général ne fait pas que faire perdre du temps : elle crée un risque de non-conformité.
Abacus Insights traite les données de santé de plus de 65 millions de membres sous des contrôles de niveau HIPAA et isolés (air-gapped). C'est précisément le type d'environnement où l'approche « explorer et deviner » cesse d'être une simple perte de temps pour devenir un risque : l'agent ne peut pas manipuler les PHI à la légère, il ne peut pas deviner le modèle de gouvernance, et chaque hypothèse erronée devient une question de conformité plutôt qu'une simple correction rapide.
Leur équipe a mis en production des agents de mappage de données et de pipeline, avec Genie Code comme interface quotidienne pour leurs ingénieurs – car il comprend déjà leurs données et fonctionne au sein de leur gouvernance, au lieu de devoir tout réapprendre depuis le début. Et ils constatent déjà des gains d'efficacité significatifs dans leur travail d'intelligence des données. Le résultat se traduit dans les chiffres : l'intégration des nouveaux clients atteint désormais sa première valeur en environ deux fois moins de temps, et l'effort manuel sur le mappage des données et la construction des pipelines a diminué d'environ 40 %.
« Nos ingénieurs de données travaillent à une échelle considérable : des milliards de dossiers de réclamations de santé, avec des dizaines de millions de données ingérées chaque jour. Genie Code a changé la donne pour nous. Il comprend déjà nos schémas, notre gouvernance et nos exigences d'isolation (air-gap). Nos ingénieurs ne passent pas la moitié de leur temps à expliquer l'environnement à un outil : ils le consacrent au problème réel. Une réduction de 40 % de l'effort manuel n'est qu'un début. À mesure que nous progressons dans notre démarche de développement axé sur les agents, nous sommes convaincus que cela va transformer radicalement la vitesse à laquelle nous passons d'un nouveau client à la première valeur produite. » - Nav Alam, CTO, Abacus Insights
La taxe de prototypage est réelle, mesurable et facultative. Les équipes qui l'ont compris n'attendent pas de s'aligner avant de construire : elles s'alignent en construisant, et déploient avant que l'élan ne s'essouffle.
(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original
Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.