Concevoir des systèmes de données et d’IA qui résistent en production

Dans la série Author Spotlight, les rédacteurs de TDS discutent avec les membres de notre communauté de leur parcours professionnel en science des données et en IA, de leurs écrits et de leurs sources d’inspiration. Aujourd’hui, nous sommes ravis de partager notre conversation avec Mike Hulls.

Mike est un responsable technique qui travaille à l’intersection de l’ingénierie des données, de l’IA et de l’architecture, aidant les organisations à transformer des paysages de données complexes en systèmes fiables et utilisables. Fort d’une solide expérience full-stack, il conçoit des solutions de bout en bout qui équilibrent la profondeur technique et la valeur commerciale. Parallèlement au travail des clients, il crée et partage des outils et des informations pratiques sur les plateformes de données, les systèmes d’IA et les architectures évolutives.

Vous considérez-vous comme un développeur full-stack ? Comment votre expérience sur l’ensemble de la pile (du frontend à la base de données) change-t-elle la façon dont vous percevez le rôle de data scientist ?

Je le fais, mais pas dans le sens de construire personnellement chaque couche. Pour moi, le full-stack signifie comprendre comment les décisions architecturales prises à une seule couche façonnent le comportement, les risques et les coûts du système au fil du temps. Cette perspective est essentielle lors de la conception de systèmes qui doivent survivre au changement.

Cette perspective influence également la façon dont je perçois le rôle de data scientist. Les modèles créés dans les cahiers ne sont qu’un début. La vraie valeur apparaît lorsque ces modèles sont intégrés dans des systèmes de production dotés de pipelines de données, d’API, de gouvernance et d’interfaces utilisateur appropriées. La science des données devient efficace lorsqu’elle est traitée comme un élément central d’un système plus vaste, et non comme une activité isolée.

Vous couvrez un large éventail de sujets. Comment décidez-vous sur quoi vous concentrer ensuite et comment savoir quand un nouveau sujet mérite d’être exploré ?

J’ai tendance à suivre les frictions récurrentes. Lorsque je vois plusieurs équipes aux prises avec les mêmes problèmes, qu’ils soient techniques ou organisationnels, je considère cela comme le signe que le problème est structurel plutôt qu’individuel et qu’il mérite d’être abordé au niveau de l’architecture ou des processus.

J’expérimente aussi délibérément les nouvelles technologies, non pas pour la nouveauté, mais pour comprendre leurs compromis. Un sujet mérite d’être abordé lorsqu’il résout un problème réel auquel je suis actuellement confronté ou révèle des risques qui ne sont pas encore largement compris. Enfin, j’écris sur des sujets que je trouve personnellement intéressants et qui méritent d’être explorés, car un intérêt soutenu est ce qui me permet d’approfondir.

Vous avez écrit sur LangGraph, MCP et les agents auto-hébergés. Selon vous, quelle est la plus grande idée fausse que les gens ont aujourd’hui à propos des agents d’IA ?

Les agents sont véritablement puissants et ouvrent de nouvelles possibilités. L’idée fausse est qu’ils sont simples. Il est aujourd’hui facile d’assembler une infrastructure cloud, de connecter un framework d’agents et de produire quelque chose qui semble fonctionner. Cette accessibilité est précieuse, mais elle masque beaucoup de complexité.

Une fois que les agents ont dépassé le stade des démonstrations, les véritables défis font surface. La gestion des états, les autorisations, le contrôle des coûts, l’observabilité et la gestion des pannes sont souvent sous-estimés. Sans limites et appropriation claires, les agents deviennent imprévisibles, coûteux et risqués à exploiter. Ce ne sont pas seulement des invites avec des outils ; ce sont des systèmes logiciels de longue durée et doivent être conçus et exploités en conséquence.

Dans votre article sur Architecture en couchesvous mentionnez que l’ajout de fonctionnalités peut souvent ressembler à une « opération à cœur ouvert ». Pour un débutant ou une petite équipe data cherchant à éviter cela, quel est votre conseil clé pour mettre en place une architecture ?

« La seule constante est le changement » est un cliché pour une bonne raison : optimisez donc le changement plutôt que la vitesse de livraison initiale. Même une forme minimale de réflexion en couches est utile : séparer la logique du domaine, le flux des applications et les problèmes d’infrastructure.

L’objectif n’est pas la perfection architecturale dès le premier jour ou une catégorisation parfaite. Il s’agit de créer des limites claires qui permettent au système d’évoluer sans réécriture constante. Une petite discipline initiale s’avère considérablement payante à mesure que les systèmes se développent.

Vous avez comparé Stratégies d’insertion PostgreSQL et a noté que « plus vite n’est pas toujours mieux ». Dans un pipeline de ML de production, quel serait le scénario dans lequel vous choisiriez délibérément une méthode d’insertion plus lente et plus sûre ?

Lorsque l’exactitude, la traçabilité et la récupérabilité comptent plus que le débit brut. Dans de nombreux pipelines, réduire le temps d’exécution de quelques secondes offre peu d’avantages par rapport au risque introduit par des garanties plus faibles.

Par exemple, les pipelines qui alimentent les rapports réglementaires, la prise de décision financière ou les ensembles de données de formation à long terme bénéficient d’une sécurité transactionnelle et d’une validation explicite. La corruption silencieuse des données est bien plus coûteuse que l’acceptation de modestes compromis en matière de performances, en particulier lorsque les données deviennent un actif à long terme sur lequel d’autres vont s’appuyer.

Dans votre Assistants personnels et agents article, vous avez construit une plateforme 100% privée et auto-hébergée. Pourquoi était-il plus important pour vous d’éviter les « coûts symboliques » et les « fuites de confidentialité » que d’utiliser un LLM plus puissant, basé sur le cloud ?

Dans mon travail quotidien, j’ai constaté que faire confiance à un système est fondamental pour son adoption. Les coûts des jetons, les flux de données opaques et les dépendances externes influencent subtilement la façon dont les systèmes sont utilisés et perçus.

J’ai également fait le choix conscient de ne pas acheminer mes données personnelles ou sensibles via des fournisseurs de cloud externes, car les garanties sur la manière dont les données seront traitées au fil du temps sont limitées. En gardant le système auto-hébergé, j’ai pu concevoir un assistant prévisible, vérifiable et conforme aux attentes européennes en matière de confidentialité. Les utilisateurs ont un contrôle total sur ce à quoi l’assistant a accès, ce qui réduit les obstacles à l’utilisation de l’assistant.

Enfin, tous les cas d’utilisation ne nécessitent pas le modèle le plus grand ou le plus cher. En dissociant le système d’un fournisseur unique, les utilisateurs peuvent choisir le modèle qui correspond le mieux à leurs besoins, en termes de capacité, de coût et de risque.

Comment voyez-vous évoluer le quotidien d’un professionnel de la data en 2026 ?

Malgré les stéréotypes courants, l’ingénierie des données et l’ingénierie logicielle sont des professions hautement sociales. Je crois fermement que la partie la plus importante du travail se déroule avant l’écriture du code : s’aligner avec les parties prenantes, comprendre l’espace du problème et concevoir des solutions adaptées aux systèmes et aux équipes existants.

Ce travail initial devient encore plus important à mesure que le développement assisté par agents accélère la mise en œuvre. Sans objectifs, contexte et contraintes clairs, les agents amplifient la confusion plutôt que la productivité.

En 2026, les professionnels des données passeront plus de temps à façonner les systèmes, à définir les limites, à valider les hypothèses et à garantir un comportement responsable dans les environnements de production.

Pour le reste de l’année 2026, quels grands sujets définiront l’année pour les professionnels des données, à votre avis ? Pourquoi?

L’IA générative et les systèmes basés sur des agents continueront de croître, mais le changement le plus important réside dans leur maturation vers des systèmes de production de premier ordre plutôt que vers des expériences.

Cette transition dépend de données fiables, de haute qualité et accessibles et de pratiques d’ingénierie robustes. En conséquence, la réflexion full-stack et la conception au niveau système deviendront de plus en plus importantes pour les organisations qui souhaitent appliquer l’IA de manière responsable et à grande échelle.

Pour en savoir plus sur le travail de Mike et rester au courant de ses derniers articles, vous pouvez le suivre sur TDS ou LinkedIn.