De Data Scientist à Architecte IA

(il n’y a pas si longtemps) alors qu’être un data scientist signifiait vivre dans un ordinateur portable, peaufiner les hyperparamètres comme si votre vie en dépendait, et dans de nombreux cas, l’ensemble du projet en dépendait effectivement.

Vous souvenez-vous de ces recherches nocturnes sur la grille ? Ou créer des pipelines d’ingénierie de fonctionnalités qui ressemblent plus à de l’art qu’à de la science ? Et la satisfaction d’obtenir une précision supplémentaire de 0,7 % d’un modèle XGBoost ?

En 2019, c’était le travail d’un data scientist ! Ce qui était logique. Si vous vouliez un modèle solide, vous deviez le construire vous-même ou travailler dur pour y parvenir. La véritable valeur réside dans la capacité à ajuster, optimiser et comprendre les données.

Désormais, l’état de l’art n’est qu’à un appel d’API. Besoin d’un modèle linguistique de pointe ? Fait. Besoin d’intégrations ou de raisonnement multimodal ? Également fait. Les parties les plus difficiles de la modélisation sont désormais gérées par des points de terminaison évolutifs, bien au-delà de ce que la plupart des équipes pourraient construire elles-mêmes.

La question est maintenant de savoir si le modèle est déjà là, où est passé le travail ?

La valeur n’est plus seulement dans le modèle. Il s’agit de la façon dont toutes les parties se connectent, communiquent et s’adaptent. Ce changement remodèle entièrement le rôle d’un data scientist.

Commentdemandez-vous ? C’est le sujet de cet article.

Qu’est-ce qui a changé ?

1. Contourner la méthode .fit()

Si vous examinez le code d’un projet d’IA moderne, vous remarquerez rapidement qu’il n’y a pas beaucoup de modélisation réelle en cours.

Vous pourriez voir un appel à un LLM ou à un modèle d’intégration, mais c’est rarement le principal défi. Le vrai travail réside dans l’ingestion des données, le routage, l’assemblage du contexte, la mise en cache, la surveillance et la gestion des tentatives.

Autrement dit, en utilisant .fit() est désormais l’une des parties les moins intéressantes du code.

2. Adaptation aux nouveaux composants

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

• Bases de données vectorielles (par exemple, Pinecone, Milvus)
• Ingénierie rapide.
• Couches de mémoire.

En plus des fonctions/appels d’agents. Quand on regarde la situation dans son ensemble, on voit qu’il ne s’agit pas d’une modélisation traditionnelle. C’est la conception du système. Une chose importante à souligner ici est qu’aucun de ces composants n’est particulièrement utile en soi. Leur pouvoir vient de la façon dont ils sont orchestrés ensemble.

3. Rassembler le tout

À l’heure actuelle, la plupart des codes de science des données consistent à relier les éléments. 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 les données entre les composants, formate les entrées, analyse les sorties, enregistre les interactions et gère l’état sur les systèmes distribués.

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

Le passage de Data Scientist à AI Architect

Le plus grand changement de mentalité aujourd’hui est qu’il ne s’agit plus simplement d’optimiser une fonction. Maintenant, vous concevez un système complet, 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 les performances du modèle ? » nous demandons maintenant, « Comment tout ce système fonctionne-t-il dans des situations réelles ?»

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

Pour suivre le rythme actuel, nous avons besoin de plus que de simples statistiques et du machine learning. Nous devons être à l’aise avec les API (telles que FastAPI ou Flask) pour le service et le routage, la conteneurisation (telle que Docker) pour le déploiement, la programmation asynchrone (en utilisant Asyncio) pour gérer plusieurs requêtes, l’infrastructure cloud pour la mise à l’échelle 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 ingénierie back-endtu as raison.

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

L’ancien contre le nouveau

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

Projet Legacy (2019) : Analyse des sentiments

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

• Collectez un ensemble de données étiqueté.
• Effectuer l’ingénierie des fonctionnalités (TF-IDF, n-grams).
• Classificateur de train (régression logistique, XGBoost).
• Ajustez les hyperparamètres.
• Déployer le modèle.

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

Projet moderne (2026) : Agent autonome de feedback client

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

• Ingérez les messages des clients en temps réel.
• Stockez les intégrations dans une base de données vectorielle.
• Récupérer le contexte historique pertinent.
• Créez dynamiquement des invites.
• Itinéraire vers LLM avec accès aux outils (par exemple, mises à jour CRM, systèmes de billetterie)
• Maintenir la mémoire conversationnelle.
• Surveillez les sorties pour en vérifier la qualité et la sécurité.

Pouvez-vous repérer ce qui manque ? Voici un indice : il n’y a pas de boucle de formation.

Cet exemple est volontairement simple, mais remarquez ce sur quoi nous nous concentrons maintenant. La récupération fait partie du système ; le modèle n’est qu’une seule pièce et la valeur vient de la façon 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 réellement faire différemment. Comment pouvez-vous avancer dans cette transition au lieu de prendre du retard ?

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. Créez de bout en bout, pas seulement des composants

Au lieu de penser : «J’ai formé un modèle», viser, «J’ai construit un système qui prend les entrées, les traite et renvoie une valeur.« Il s’agit désormais d’une vision d’ensemble et non d’une seule tâche.

2. Apprenez juste assez de backend pour être dangereux

Vous n’avez pas besoin de devenir ingénieur backend à temps plein, mais vous devez en savoir suffisamment pour construire votre système. Se concentrer sur:

• Lancer une API simple (FastAPI suffit)
• Traitement des requêtes de manière asynchrone
• Journalisation et gestion des erreurs
• Déploiement de base (Docker + une plateforme cloud)

3. Soyez à l’aise avec l’ambiguïté

Les systèmes d’IA modernes ne sont pas déterministes comme les modèles traditionnels. Cela les rend plus difficiles à utiliser, car désormais vous ne vous contentez plus de déboguer du code ; vous déboguez plutôt le comportement.

Cela signifie qu’il faut répéter les invites, concevoir des mécanismes de repli et évaluer les résultats qualitativement, et pas seulement quantitativement.

4. Mesurez ce qui compte réellement

La précision n’est plus toujours la mesure principale. Désormais, 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 précis à 95 % mais inutilisable en production est pire qu’un système précis et fiable à 85 %.

La pensée finale

Dans notre domaine, il est toujours tentant de rechercher ce qui semble le plus « technique », le modèle le plus récent, la plus grande référence, l’architecture la plus flashy.

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

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

Vous ne pouvez pas sous-traiter ou cacher cette partie derrière une API. Et vous ne pouvez certainement pas l’automatiser.

Ne visez donc pas uniquement à construire le moteur d’une voiture. Visez à être la personne qui comprend où la voiture doit aller, puis qui construit le système pour y arriver.