Contexte technique
J'ai regardé une récente interview de Martin Kleppmann non pas pour les discussions générales sur l'IA. Ce qui m'intéressait, c'était de voir comment une personne issue du monde des systèmes à forte intensité de données adapte ses principes à l'implémentation de l'IA, à l'heure où les modèles s'immiscent dans les données, les flux de travail et les API internes.
Et c'est là que ça devient intéressant. Kleppmann ne vend pas de la magie ; il dit essentiellement que si l'IA doit changer quelque chose dans un système, on ne peut pas simplement lui donner accès à la base de données et espérer que tout se passe bien.
Sa ligne de pensée est très saine : les modèles doivent fonctionner via des interfaces sécurisées où les modifications peuvent être vérifiées, discutées et fusionnées, presque comme du code. Pour moi, c'est un signal fort : une véritable automatisation par l'IA dans les produits sérieux ne reposera pas sur le principe de “l'agent a tout fait tout seul”, mais sur des opérations contrôlées avec une piste d'audit claire.
Le deuxième point important concerne les données elles-mêmes. L'architecture classique ne couvre plus toutes les charges de travail de l'IA, car à côté des index traditionnels, on trouve désormais des embeddings, la recherche vectorielle, la recherche sémantique et le RAG. De plus, il y a les données multimodales, pour lesquelles les anciens formats de stockage sont souvent peu pratiques ou tout simplement trop lents.
Un autre point qui me parle : il ne faut pas perdre la compréhension du bas niveau. Lorsqu'il y a trop d'abstractions et d'outils d'IA, les équipes oublient vite comment fonctionnent réellement les moteurs de stockage, la réplication, la cohérence et les compromis multi-régions. Ensuite, elles s'étonnent que l'agent écrive du beau code, mais que le système s'effondre sous la charge.
En même temps, Kleppmann n'abandonne pas les fondations de DDIA. La réplication reste essentielle, et le sharding manuel n'est plus le héros universel, surtout dans le cloud et sur de grosses machines. La nouveauté n'annule pas les fondamentaux, elle s'y superpose.
Ce que cela change pour l'entreprise et l'automatisation
Je soulignerais trois leçons pratiques. Premièrement : si vous développez des solutions d'IA pour les entreprises, la couche de données doit désormais être conçue dès le départ pour la récupération, la révision et l'application sécurisée des changements, et non pas être ajoutée après coup.
Deuxièmement : les équipes qui ne confondent pas les démos avec la production gagneront. Celles qui donnent trop de liberté aux agents sans frontières d'API, journalisation et contrôle humain perdront.
Troisièmement : le coût de l'erreur augmente. Une mauvaise intégration de l'IA aujourd'hui n'affecte pas seulement l'UX, mais aussi les données, les processus et les risques juridiques.
C'est précisément ce genre de points de friction que j'aborde dans les projets du Nahornyi AI Lab : où le RAG est-il nécessaire, où une recherche classique suffit-elle, où faut-il un agent, et où un flux de travail rigide est-il préférable ? Si votre automatisation par l'IA se heurte déjà au chaos des données ou à des droits d'accès dangereux, nous pouvons nous asseoir et concevoir une architecture qui aide réellement l'entreprise au lieu de créer une nouvelle catégorie de problèmes.