Vos data scientists codent avec des agents IA. Savez-vous ce que ça a changé ?

Depuis deux ans, l'essentiel du code de votre équipe data est écrit avec Copilot, Cursor, Claude Code ou ChatGPT. Personne ne l'a décidé formellement ; c'est arrivé poste par poste. Chacun vous dira qu'il va plus vite, et sur une partie du travail c'est exact.

Trois questions restent cependant sans réponse. La qualité du code produit s'améliore-t-elle ou se dégrade-t-elle ? Le gain de productivité est-il réel ou perçu ? Et ce qui part vers les modèles — votre code, vos données, vos méthodes — représente-t-il un risque pour l'entreprise ?

Cet audit y répond à partir de votre code et de vos pratiques, pas à partir de généralités sur l'IA.

Qualité et productivité : ce que produisent réellement les agents

Les résultats de recherche sont plus nuancés que les promesses des éditeurs. Dans un essai randomisé de METR, des développeurs expérimentés travaillant avec des outils IA sur leurs propres projets ont mis 19 % de temps en plus, tout en s'estimant 20 % plus rapides. À Stanford, Perry et ses coauteurs ont montré que les participants assistés écrivaient un code moins sûr et en étaient pourtant plus confiants. Prather et ses coauteurs décrivent un écart qui se creuse : l'assistance profite à ceux qui maîtrisent le sujet et nuit aux autres, en leur donnant une illusion de compétence. Bastani et ses coauteurs en établissent le mécanisme sur près d'un millier de participants : une IA sans garde-fous améliore les résultats immédiats et dégrade l'apprentissage, parce qu'on cesse de comprendre ce qu'on obtient.

Le principe est simple. Un agent fait gagner du temps à qui sait déjà faire, parce qu'il sait juger et corriger la proposition. À qui ne maîtrise pas le sujet, il propose une solution qui s'écarte de la bonne sans que rien ne le signale. La qualité finale tient aux petits ajustements de l'expert ; la dégradation tient aux petits renoncements à comprendre.

En data science, ce mécanisme est plus dangereux qu'en développement logiciel. Un bug applicatif se voit : le programme plante, un test échoue. Une erreur d'analyse ne se voit pas. Une fuite d'information entre entraînement et test, une validation croisée mal construite, une hypothèse statistique ignorée produisent un résultat plausible, présenté avec assurance, et repris dans une décision. Les notebooks n'ont pas de tests, le code exploratoire finit en production, et le modèle qui a écrit l'analyse ne connaissait rien de vos données.

Ce que j'apporte. Je forme des équipes à Python depuis 2011 (arnaudlegout.fr/formation) et je code moi-même quotidiennement avec ces agents. Je reconnais le code qu'un praticien compétent n'aurait pas écrit, et l'analyse qui a l'air juste sans l'être. L'audit établit, par type de tâche et par profil, où l'agent accélère l'équipe et où elle perd le contrôle de ce qu'elle produit.

Données, code et méthodes : ce qui sort de l'entreprise, et ce que ça vous coûte

Là aussi, la recherche a devancé les pratiques. Carlini et ses coauteurs ont montré qu'on peut extraire d'un modèle des extraits textuels de ses données d'entraînement, y compris du code, et que cette mémorisation augmente avec la taille des modèles. Greshake et ses coauteurs ont établi qu'un agent qui lit des documents ou des pages web peut recevoir des instructions cachées et exfiltrer ce à quoi il a accès — le risque grandit à mesure que les agents gagnent en autonomie et en outils. Schuster et ses coauteurs ont montré qu'un assistant de complétion de code peut être empoisonné pour suggérer du code vulnérable.

Concrètement, chaque requête envoie du contexte : extraits de code, noms de colonnes, échantillons de données, parfois des chiffres d'affaires ou des données clients. Selon l'outil, l'abonnement et la configuration, ce contexte est conservé ou non, réutilisé pour l'entraînement ou non, hébergé en Europe ou non. L'usage déborde souvent le cadre contractuel : un compte personnel pour dépanner, une extension installée sans validation.

La question n'est pas seulement de savoir ce qui sort, mais si ça vous nuit. Un algorithme métier qui vous distingue de vos concurrents, transmis à un modèle qui s'entraîne dessus, devient une suggestion disponible pour tout le monde. Des données clients transmises hors d'Europe engagent votre responsabilité au titre du RGPD. Un agent autonome qui accède à vos bases et à Internet est une cible d'exfiltration que vos contrôles de sécurité ne couvrent pas. Et une dépendance à un fournisseur dont les conditions changent est une question de souveraineté que peu d'équipes ont posée.

Ce que j'apporte. Une part importante de mes travaux de recherche, publiés dans les conférences de référence en sécurité et protection de la vie privée, porte sur la mesure des fuites de données et des menaces sur Internet. L'audit établit ce qui sort réellement, vers qui, sous quelles conditions, et qualifie le risque selon votre activité : ce qui est anodin, ce qui est réglementaire, ce qui met en jeu votre avantage compétitif.

Comment je procède

L'audit dure trois à cinq jours, en partie sur site.

• Entretiens individuels sur la pratique réelle des agents : pour quelles tâches, avec quel niveau de relecture, avec quels outils et quels comptes.
• Revue d'un échantillon de notebooks, scripts et pipelines produits sur les derniers mois, avec l'historique Git, pour distinguer ce qui a été généré, compris et repris.
• Observation de sessions de travail, pour voir comment les propositions sont acceptées, modifiées ou rejetées.
• Vérification de validité sur deux ou trois analyses critiques pour votre activité.
• Cartographie des flux : outils, abonnements, configuration, clauses de rétention et d'entraînement, données effectivement transmises, et sensibilité de chacune pour l'entreprise.

Ce que vous recevez

Un rapport écrit qui répond aux trois questions, avec les observations qui les fondent ; une évaluation des pratiques par type de tâche et de profil ; des règles d'usage, de relecture et de vérification adaptées à votre équipe ; les mesures de protection du code, des données et des méthodes à mettre en place, par ordre de priorité. Deux restitutions : l'une à l'équipe, orientée pratiques ; l'autre à la direction, orientée risques et décisions.

L'objectif n'est pas de restreindre l'usage des agents. C'est que votre équipe en tire la productivité qu'ils permettent, sans perdre la maîtrise de ce qu'elle produit ni la propriété de ce qu'elle sait.

Conseil récurrent

Les outils et les usages évoluent vite, et les règles adoptées après un audit se relâchent ou deviennent obsolètes en quelques mois. Une demi-journée à une journée par mois permet de relire un échantillon récent, de vérifier ce qui a réellement été retenu par l'équipe, et d'ajuster les règles aux outils du moment.

Pour qui

Les équipes data science, data engineering et R&D de PME, d'ETI et de startups en croissance, dont les analyses, les modèles et le code sont un actif de l'entreprise.

Pourquoi moi

Directeur de recherche à Inria, habilité à diriger des recherches, j'ai construit ma carrière sur l'analyse expérimentale de très grands volumes de données : le graphe complet de Twitter, l'intégralité des transactions Bitcoin, des millions d'adresses IP observées en continu. Une part importante de ces travaux porte sur la protection des données et la mesure de ce qui fuit sur Internet. J'ai aussi été adjoint du CTO d'une startup, puis fondateur d'une autre : je connais les arbitrages d'une équipe qui doit livrer.

Mon parcours et mes recherches →

Diagnostic préalable

Avant toute chose, un appel d'une heure, gratuit et sans engagement, pour comprendre votre situation et vérifier que je peux vous être utile. S'il y a matière, un diagnostic d'une à deux journées : entretiens avec le responsable et deux ou trois membres de l'équipe, revue rapide d'un échantillon de code, restitution orale et recommandations écrites. Il conclut sur ce qui mérite d'être approfondi, par un audit ou par une formation.