Architecte IA : l'évolution cruciale des data scientists

L'évolution du rôle de data scientist vers l'architecte IA

La transformation du métier de data scientist

Il fut un temps où le quotidien d'un data scientist se résumait à jongler avec des hyperparamètres dans un notebook, chaque ajustement pouvant déterminer le succès d'un projet. Les longues nuits passées à effectuer des recherches sur grille ou à créer des pipelines d'ingénierie des caractéristiques étaient monnaie courante. La satisfaction de gagner un maigre 0,7 % de précision supplémentaire sur un modèle XGBoost était alors inestimable.

En 2019, cette approche était la norme. Pour obtenir un modèle performant, il fallait le construire de toutes pièces ou travailler d'arrache-pied pour l'optimiser. La valeur résidait dans la capacité à ajuster, optimiser et comprendre les données en profondeur.

Aujourd'hui, les modèles de pointe sont accessibles via de simples appels d'API. Que ce soit pour un modèle linguistique performant ou des embeddings sophistiqués, tout est à portée de main. Les aspects les plus complexes de la modélisation sont désormais pris en charge par des services évolutifs, bien au-delà de ce que la plupart des équipes pouvaient réaliser seules.

La question qui se pose maintenant est : si le modèle est déjà disponible, où se situe le véritable travail ?

La valeur ne réside plus uniquement dans le modèle lui-même. Elle se trouve dans la manière dont les différentes parties interagissent, se connectent et s'adaptent. Ce changement redéfinit complètement le rôle du data scientist.

Comment ce changement s'opère-t-il ?

C'est précisément ce que cet article explore.

1. L'ère post-.fit()

En examinant le code d'un projet d'IA moderne, on constate rapidement que la modélisation proprement dite n'est plus au cœur des préoccupations. Vous pourriez apercevoir un appel à un LLM ou à un modèle d'embedding, mais ce n'est rarement là que réside le principal défi. Le véritable travail consiste à ingérer des données, les acheminer, assembler le contexte, mettre en cache, surveiller et gérer les retries.

Autrement dit, l'utilisation de la méthode .fit() est devenue l'une des parties les moins captivantes du code.

2. L'adaptation aux nouveaux composants

Aujourd'hui, au lieu de se concentrer sur les détails internes du modèle, nous assemblons des systèmes à partir de composants prêts à l'emploi. Une pile de modélisation typique inclut désormais :

• Des bases de données vectorielles comme Pinecone ou Milvus
• L'ingénierie des prompts

En plus des appels de fonctions et d'agents. En examinant la situation dans son ensemble, on réalise qu'il ne s'agit pas de modélisation traditionnelle. C'est de la conception de systèmes. Un point crucial à souligner ici est qu'aucun de ces composants n'est particulièrement utile en soi. Leur puissance provient de la manière dont ils sont orchestrés ensemble.

3. L'assemblage des pièces

Actuellement, la majorité du code en science des données concerne la connexion des pièces. Il ne s'agit pas d'algèbre linéaire, d'optimisation ou même de statistiques.

Il s'agit d'écrire du code qui déplace des données entre les composants, formate les entrées, analyse les sorties, journalise les interactions et gère l'état à travers des systèmes distribués.

Si vous mesurez votre code, vous constaterez que seulement 10 à 20 % est consacré à l'utilisation d'un modèle (appels API, inférence), tandis que 80 à 90 % est consacré à l'orchestration : gestion du flux de données, intégration et infrastructure.

Le passage de Data Scientist à Architecte IA

Le plus grand changement de mentalité aujourd'hui est que vous ne vous contentez plus d'optimiser une fonction. Maintenant, vous concevez un système entier, en pensant à la latence, au coût, à la fiabilité et à la manière dont les gens interagissent avec lui.

Au lieu de demander : « Comment puis-je améliorer la performance du modèle ? », nous demandons maintenant : « Comment fonctionne ce système dans des situations réelles ? »

Je sais ce que vous pensez : c'est un défi complètement différent ! Cela a été inconfortable pour beaucoup de gens, y compris moi, lorsque ce changement s'est produit pour la première fois.

Pour suivre la pile d'aujourd'hui, nous avons besoin de plus que de simples statistiques et de machine learning. Nous devons être à l'aise avec les API (comme FastAPI ou Flask) pour le service et l'acheminement, la containerisation (comme Docker) pour le déploiement, la programmation asynchrone (en utilisant Asyncio) pour gérer plusieurs requêtes, l'infrastructure cloud pour l'évolutivité et la surveillance, et les bases de l'ingénierie des données pour les pipelines et le stockage.

Si vous pensez que cela ressemble beaucoup à l'ingénierie backend, vous avez raison.

Ce changement a brouillé la frontière entre data scientist et ingénieur. Les personnes qui réussissent sont celles qui peuvent travailler confortablement dans les deux domaines.

L'ancien vs. Le nouveau

La question clé maintenant est : à quoi ressemble ce changement dans le code ?

Projet Héritage (2019) : Analyse de Sentiment

Beaucoup d'entre nous ont travaillé sur des projets comme celui-ci. Le processus est simple :

• Collecter un ensemble de données étiquetées.
• Effectuer l'ingénierie des caractéristiques (TF-IDF, n-grams).
• Entraîner un classificateur (régression logistique, XGBoost).
• Ajuster les hyperparamètres.

Le succès ici dépend de la qualité de votre ensemble de données et de votre modèle.

Projet Moderne : Agent Autonome de Retour Client

Le processus est différent maintenant. Pour construire un système aujourd'hui, vous devez :

• Ingérer des messages clients en temps réel.
• Stocker des embeddings dans une base de données vectorielle.
• Récupérer le contexte historique pertinent.
• Construire dynamiquement des prompts.
• Acheminer vers un LLM avec accès aux outils (par exemple, mises à jour CRM, systèmes de billetterie).
• Maintenir une mémoire conversationnelle.
• Surveiller les sorties pour la qualité et la sécurité.

Pouvez-vous repérer ce qui manque ? Voici un indice : il n'y a pas de boucle d'entraînement.

Cet exemple est simple par souci de clarté, mais remarquez sur quoi nous nous concentrons maintenant. La récupération fait partie du système ; le modèle n'est qu'un élément, et la valeur provient de la manière dont tout se connecte et fonctionne ensemble.

Comment commencer à penser comme un Architecte IA

Maintenant que nous savons ce qui a changé, parlons de ce que vous devriez faire différemment. Comment pouvez-vous avancer avec ce changement au lieu de rester à la traîne ?

La réponse courte : commencez à construire des systèmes, pas seulement des modèles.

La réponse plus longue : concentrez-vous sur le développement de ces compétences :

1. Construire de bout en bout, pas seulement des composants

Au lieu de penser : « J'ai entraîné un modèle », visez : « J'ai construit un système qui prend une entrée, la traite et renvoie une valeur. » Il s'agit désormais de la vue d'ensemble, pas seulement d'une tâche.

1. Apprendre juste assez de backend pour être dangereux

Vous n'avez pas besoin de devenir un ingénieur backend à temps plein, mais vous devriez en savoir assez pour construire votre système. Concentrez-vous sur :

• Lancer une API simple (FastAPI suffit)
• Gérer les requêtes de manière asynchrone
• Journaliser et gérer les erreurs
• Déploiement de base (Docker + une plateforme cloud)

1. Devenir à l'aise avec l'ambiguïté

Les systèmes IA modernes ne sont pas déterministes comme les modèles traditionnels. Cela les rend plus difficiles à travailler, car vous ne déboguez pas seulement du code ; vous déboguez plutôt un comportement.

Cela signifie itérer sur les prompts, concevoir des mécanismes de secours et évaluer les sorties qualitativement, pas seulement quantitativement.

1. Mesurer ce qui compte réellement

La précision n'est plus toujours la principale métrique. Maintenant, la latence, le coût par requête, la satisfaction des utilisateurs et le taux d'achèvement des tâches comptent davantage.

Un système qui est 95 % précis mais inutilisable en production est pire qu'un qui est 85 % précis et fiable.

La pensée finale

Dans notre domaine, il y a toujours une tentation de poursuivre ce qui semble le plus « technique », le modèle le plus récent, le plus grand benchmark, l'architecture la plus flashy.

Mais la partie la plus précieuse de ce travail a toujours été, et sera toujours, le côté humain ! Comprendre le problème. Savoir ce que nous essayons de résoudre est plus important que les données ou le modèle que nous utilisons.

Poser des questions comme : « Quel est le besoin ici ? Qu'est-ce qui importe pour l'utilisateur ? Que signifie réellement 'bon' dans ce contexte ? » fait une énorme différence dans ce que vous construisez.

Vous ne pouvez pas externaliser ou cacher cette partie derrière une API. Et vous ne pouvez certainement pas l'automatiser.

Alors, ne visez pas seulement à construire le moteur d'une voiture. Visez à être la personne qui comprend où la voiture doit aller, puis construit le système pour l'y amener.