Bonjour à tous, ravie de vous retrouver pour cette nouvelle interview. Aujourd’hui, on ne va pas parler d’IA en théorie, ni de roadmap stratégique. On va parler du quotidien des équipes data, de ce que l’IA change concrètement dans la façon de coder, d’apprendre, de structurer et de collaborer.
Mon invité du jour s’appelle Vincent Bilbeissi. Il est Principal Engineer chez Vusion Group, leader mondial des étiquettes intelligentes et des solutions digitales pour le retail. C’est un ancien CEO qui a choisi de revenir temporairement à la technique, et c’est justement depuis cette position qu’il observe aujourd’hui la transformation la plus profonde : celle du métier d’ingénieur data à l’ère de l’IA.
Nous allons nous poser ensemble une question simple, mais finalement très structurante : faire ou faire faire ?
Tu as une vision très opérationnelle des pratiques d’ingénierie. Est-ce que tu te souviens du moment où tu as compris que l’IA n’allait pas seulement accélérer le travail des équipes, mais profondément redéfinir leur manière de faire de la data ?
Oui. Je faisais partie des sceptiques, j’étais assez sceptique au démarrage. Les résultats étaient intéressants, sans être médiocres, mais ils n’étaient pas du tout au niveau auquel ils sont aujourd’hui.
Je prends l’exemple du code. Aujourd’hui, la qualité du code généré par un LLM est assez impressionnante, à un très très bon niveau. C’est là que j’ai pris le sujet en plein visage. La prise de conscience s’est faite à ce moment-là : il faut s’approprier ces outils, parce que c’est un avantage, une sorte de super pouvoir, que d’en être en maîtrise.
Et puis il y a un vrai sujet derrière. On parle beaucoup d’automatiser les rôles des uns et des autres. Pour moi, le véritable enjeu, c’est de s’approprier l’automatisation, d’être actif dans ce changement plutôt que de le subir.
Beaucoup d’équipes data fonctionnent encore sur un modèle assez artisanal. Selon toi, est-ce que l’IA vient casser un plafond de verre, ou est-ce que c’est simplement une nouvelle couche d’optimisation ?
Je pense que c’est vraiment une possibilité d’optimiser, d’aller plus loin et de grandir. Aujourd’hui, on est capable d’aller beaucoup plus vite, de faire beaucoup plus de choses, mais aussi d’apprendre beaucoup mieux.
Il faut se forcer à comprendre au-delà de la superficie, sur tout un tas de sujets. Pour moi, c’est un vrai moyen de monter en compétence sur des sujets que je ne maîtrisais pas. J’ai une sorte de tuteur à côté de moi : je peux lui poser des questions, comprendre un texte compliqué, aller plus vite.
Il y a en revanche un vrai sujet sur la partie automatisation et remplacement, parce qu’on peut très rapidement se mettre dans le siège passager et devenir passif dans la manière dont les choses sont générées. C’est un vrai danger. C’est un choix très personnel : le mien, c’est de continuer à être actif, de faire travailler mon cerveau, tout en utilisant ces outils pour être beaucoup plus productif.
Tu n’opposes donc pas l’automatisation et le fait de garder la main. C’est plutôt automatiser en gardant la main ?
Oui, complètement. Je pense aussi que l’humain est en train de devenir le bottleneck par rapport à la machine, qui peut aller beaucoup plus vite et faire beaucoup plus. C’est là qu’il faut trouver le bon équilibre.
Quand beaucoup de code est généré, comment fait-on pour le relire, pour le maintenir, pour le comprendre ? Est-ce qu’on veut laisser la machine générer tout le code toute seule ? On est capable d’automatiser un process de bout en bout : de la lecture des spécifications à la production du code, à la review, jusqu’au déploiement. Jusqu’à quel niveau veut-on aller ? Chaque équipe est libre de faire ses choix, mais je pense qu’il faut faire attention.
Sur le rendu, tout le monde a vécu ça : on se retrouve parfois à repartir de zéro parce que le livrable ne correspond pas, ou parce qu’on a besoin de faire évoluer des choses. Il peut donc y avoir du temps perdu, mais aussi du temps gagné.
Est-ce qu’il y a un cadre, des conditions sine qua non pour que tout cela fonctionne ? Tu me parlais d’un framework structuré.
Oui, tout à fait. On parlait justement de devoir tout refaire à zéro quand on ne cadre pas les choses. Pour que ce soit pertinent, il va falloir itérer.
Chaque équipe va devoir construire son propre framework. Il n’y a pas de solution sur étagère qu’on peut utiliser directement, chaque équipe est différente. Ce qui est important, c’est de bien cadrer la manière dont le code, ou autre chose, va être généré par l’IA, de façon à respecter le process, les guidelines, une manière d’écrire et de structurer le code.
Cette structure, c’est à nous de la créer pour que l’IA puisse remplir les trous. C’est vraiment ce contexte qu’il faut préparer pour que l’IA soit capable de générer quelque chose de cohérent, que nous serons en mesure de maintenir dans la durée puisqu’il respecte notre manière de travailler et ce que nous avons rédigé jusqu’ici.
Un framework à trous, c’est intéressant comme image.
Oui, complètement. Sur certaines tâches, des calculs d’indicateurs par exemple, un framework solide, avec le bon contexte et les bonnes specs, va permettre à l’IA de générer du code qui correspond à ce qui est demandé.
Si on reste flou sur ce qu’on a besoin de faire, c’est exactement comme pour nous : si on n’est pas clair sur la demande et sur le besoin, le résultat sera médiocre. Ce sont des choses assez logiques, on retranscrit finalement ce qu’on faisait déjà, sauf que la machine peut le faire à notre place.
Est-ce que cette transformation des pratiques peut aussi devenir un sujet d’attractivité et de rétention des talents tech ?
Je pense que oui. Je vois surtout deux profils, deux points de vue différents sur le marché. Il y a ceux qui sont plutôt frileux, parce qu’on parle, entre guillemets, de les remplacer. Ils sont inquiets à l’idée qu’une entreprise automatise X % de la génération de code, et cela peut effectivement être inquiétant.
De l’autre côté, au contraire, c’est un vrai levier potentiel, sous réserve de le faire en bonne intelligence, pour accélérer l’apprentissage et grandir d’un point de vue carrière. C’est aussi se donner la capacité d’expérimenter. Ce qui est important, en tant qu’équipe qui va utiliser ces outils, c’est de se donner le droit de se tromper, d’apprendre, d’expérimenter et de comprendre ce qui se passe sous le capot. Encore une fois, ne pas rester en superficie, mais creuser ce qu’il y a en dessous et comprendre pourquoi on obtient tel résultat et pas un autre.
Passons du pourquoi au comment. Concrètement, comment est-ce que l’IA s’est infiltrée dans le quotidien des équipes data ?
Selon les personas et les rôles dans l’équipe, c’est assez différent.
Prenons un data analyst, qui pouvait passer son temps à faire des dashboards et à traiter des tickets avec des demandes d’extraction et de préparation d’analyse. Aujourd’hui, l’IA, sous réserve encore une fois d’avoir le bon contexte sémantique, est capable de répondre à ces questions. On peut même déléguer cette tâche en rendant la donnée accessible en self-BI, avec des questions posées en langage naturel.
Via les LLM, le métier peut se débrouiller pour sortir une bonne partie des questions qu’il avait l’habitude de poser aux analystes. Et c’est là que ça devient plus intéressant pour l’analyste : il peut passer du temps avec les métiers, comprendre leurs besoins, creuser, aller plus loin, re-challenger, plutôt que d’être dans l’urgence de répondre à une file de tickets.
Ce n’est plus le petit quotidien, ce sont des questions plus poussées.
Exactement. On peut aller beaucoup plus loin et rediscuter ensemble, parce qu’on passe sans doute moins de temps dans son coin.
Sur la partie machine learning, le métier change un peu, parce qu’il faut maintenant comprendre ces nouveaux modèles, qui évoluent et atteignent une certaine maturité. Ça bouge tellement vite qu’il faut faire de la veille, et pour faire de la veille, il faut lire des articles et des publications.
Cela rejoint ce que je disais un peu plus tôt : vous prenez un article ou une documentation, vous les mettez à disposition d’un LLM, et le LLM est capable de répondre à des questions dessus. Je le fais plusieurs fois par semaine. J’essaie d’implémenter un article en m’aidant d’un LLM à côté de moi, qui va valider ce que je fais par rapport au contenu et à ce que j’ai compris, et à qui je peux reposer des questions.
Et sur la data quality ?
Ce sont des tâches généralement un peu rébarbatives. C’est un peu le sale boulot : aller vérifier si les chiffres sont bons, si on respecte bien certaines règles.
Là, on rejoint le framework dont je parlais. Si on dispose d’un framework de data quality, avec des exemples de code et une façon de générer et d’implémenter des tests sur la donnée, on est en mesure de confier un ticket Jira à un LLM ou à un agent, qui explique ce qu’il y a à faire. L’agent va utiliser le framework et la boîte à outils nécessaire pour implémenter le code et les tests, voire aller plus loin avec des outils de monitoring, refaire une passe et alerter sur ce qui ne va pas.
On peut aussi lui demander son avis : il a accès à la donnée, il peut dire où l’on peut évaluer et ce qui manque. Il y a un gain de temps énorme sur ces sujets, qui prennent beaucoup de temps.
Et le Data Scientist ?
Pour moi, c’est un vrai retour, c’est un peu la revanche des data scientists. Le marché était parti vers une logique de spécialisation, que ce soit sur le machine learning, le DataOps ou le data engineering, et le data scientist était un peu mis de côté.
Aujourd’hui, avec la quantité de données produite par les LLM et les agents, il va falloir que quelqu’un regarde cette donnée. Un data scientist est très bien équipé, à mon sens, avec toute sa boîte à outils, pour faire ça à grande échelle, en poussant même vers l’automatisation de l’évaluation des LLM.
Il va donc y avoir de plus en plus de demandes de data scientists pour comprendre la qualité et la pertinence de ce qui est produit par les LLM. Et avec en plus une expertise dans un domaine, cela devient encore plus pertinent.
Tu occupes un poste de Principal Engineer. Comment vois-tu ton rôle ? Plutôt relecteur, plutôt facilitateur ?
Il est encore en cours de définition, ce n’est pas si simple à définir, mais je me considère plutôt comme un facilitateur, qui apporte une certaine expertise technique.
Je m’écarte un peu de la vision stratégique et je suis davantage là en amont des sujets, voire en cours de sujet, pour intervenir, aider, donner une direction technique et débloquer des situations complexes. C’est la posture que j’essaie d’avoir quand on me demande d’intervenir.
Quand on est CDO et qu’on doit accompagner son équipe data face aux impacts de l’IA, tu conseillerais quoi ?
Premièrement, bien identifier les cas d’usage où il y a de la donnée, où les stakeholders sont à l’écoute, et où il y a un vrai ROI derrière, si l’on arrive à le mesurer.
Ensuite, clarifier les rôles et les responsabilités. Avec l’IA, beaucoup de monde a la capacité de participer, mais il va falloir définir qui implémente, qui déploie en production, qui évalue l’output, comment on le fait, de qui c’est la responsabilité et qui maintient dans la durée.
Formaliser les process, aussi. C’est comme n’importe quel autre sujet data : il faut être au clair. Si c’est flou, la réponse et le livrable seront flous eux aussi, et les performances ne seront pas au niveau.
Il faut également accepter que l’IA devient une commodité. Beaucoup de choses sont disponibles off the shelf. Il faut voir les modèles d’IA comme des composants remplaçables, qui évoluent très vite. Il faut donc mettre en place ce qu’il faut pour être capable de les remplacer rapidement quand de nouveaux modèles arrivent ou quand des services tombent. Il va falloir être beaucoup plus flexible.
Et enfin, le framework, qui est pour moi la clé, parce qu’il donne de la structure et s’insère dans le workflow des équipes. Cela rejoint ce qu’on fait classiquement en projet data, mais ça va beaucoup plus vite.
Le mot de la fin
Merci infiniment, Vincent, pour cet échange. Ce que je trouve intéressant, c’est que pour une fois, on parle d’adoption du côté des experts. D’habitude, on parle de culture et de métiers, mais l’IA oblige aussi les ingénieurs à se transformer, et rien de tout cela n’est une évidence.
Il y a évidemment des hard skills qu’il va falloir mettre à jour sans arrêt, grâce aux tuteurs qu’on a désormais sur l’épaule. Mais je pense que la vraie différence se joue ailleurs, surtout dans les soft skills : la curiosité, le sens critique, l’agilité. Ce sont des qualités humaines qu’il va falloir développer, avec un état d’esprit presque d’explorateur.
L’expert ne peut plus rester seul dans sa tour d’ivoire. Il doit interagir en permanence avec le business, comprendre les usages, expliquer ses choix. Chez Datalogy, nous avons d’ailleurs un atelier qui marche très bien pour ça : Storytelling appliqué aux enjeux data, spécial experts tech. C’est un atelier que j’anime moi-même, face à des data scientists et des data analysts, et qui leur donne toutes les clés pour porter leur message et entrer en interaction avec les métiers.
Parce qu’à l’ère de l’IA, la performance ne vient pas seulement de la maîtrise technique. Elle vient de la capacité des experts à rendre leur expertise compréhensible et partageable, pour qu’elle devienne actionnable par les métiers et par tous ceux qui pourront en profiter.
