Data science : faut-il encore savoir coder à l’heure du no-code et de l’IA ?

En décembre 2024, la question n’est plus simplement de savoir si l’on peut travailler avec des données sans programmer. Les outils no-code, low-code et les assistants d’IA générative le rendent possible pour un nombre croissant de tâches. La question décisive est plutôt la suivante : dans quels cas le code apporte-t-il une valeur irremplaçable, et dans quels cas ralentit-il inutilement un projet ?

La data science se situe au croisement de plusieurs savoir-faire : comprendre un besoin métier, préparer des données, choisir une méthode d’analyse, interpréter un résultat et le rendre utilisable dans une organisation. Écrire du code peut intervenir à chacune de ces étapes, mais ce n’est pas la seule manière d’avancer. Cette évolution redessine à la fois le rôle des data scientists, celui des équipes métier et celui des directions des systèmes d’information.

La data science face à l’obsolescence rapide des compétences

Le secteur technologique manque de profils spécialisés, alors même que les compétences attendues changent rapidement. Les entreprises recherchent des personnes capables de manipuler des données, de bâtir des modèles et de transformer les résultats en décisions concrètes. Or, une formation technique n’est jamais acquise définitivement : nouveaux outils, nouvelles pratiques de déploiement, nouveaux usages de l’intelligence artificielle et exigences de sécurité renouvellent constamment le métier.

L’ampleur de ce phénomène apparaît dans le constat repris d’une étude de l’OCDE : la durée de vie d’une compétence technique serait passée de 30 ans en 1987 à seulement deux ans en 2024. Il faut lire ce chiffre comme un indicateur de la vitesse de renouvellement des connaissances, et non comme l’idée que tout savoir devient inutile au bout de deux ans. Les fondamentaux, tels que le raisonnement statistique, la qualité des données ou la compréhension d’un métier, restent essentiels. Ce sont surtout les outils et les méthodes qui évoluent vite.

Pour les professionnels, le défi est double. Il faut continuer à apprendre, tout en produisant des analyses et des solutions opérationnelles. Pour les entreprises, il ne suffit donc pas de recruter des spécialistes rares : elles doivent aussi équiper leurs équipes, organiser la montée en compétences et éviter de réserver les données à une poignée d’experts.

Ce que le code permet encore de faire mieux

Programmer reste central dès qu’un projet demande un contrôle fin. Le code permet notamment de traiter une logique métier très spécifique, d’automatiser des tâches complexes, d’adapter précisément un algorithme, de connecter des systèmes hétérogènes ou de gérer des volumes et des contraintes qui dépassent les possibilités d’une interface visuelle.

Un data scientist ne se définit toutefois pas par sa seule capacité à écrire des instructions. Son rôle est de construire une solution viable de bout en bout : poser les bonnes questions, évaluer la qualité d’un jeu de données, tester une hypothèse, mesurer les limites d’un modèle et expliquer le résultat à celles et ceux qui devront l’utiliser. Un modèle techniquement sophistiqué mais fondé sur des données inadaptées ou mal interprété ne résout aucun problème métier.

Le code offre également une forte capacité de personnalisation. Lorsqu’une organisation veut créer un pipeline de données particulier, c’est-à-dire une chaîne d’étapes qui collecte, transforme et exploite des informations, elle peut régler finement chaque composant. Cet avantage a une contrepartie : il faut documenter, maintenir, tester et faire évoluer ce qui a été produit. Un programme difficile à reprendre par une autre équipe devient une dette technique, même s’il fonctionne correctement au départ.

L’enjeu n’oppose donc pas des spécialistes qui codent à des utilisateurs qui ne codent pas. Il consiste à distinguer les situations où le développement sur mesure est indispensable de celles où une solution plus accessible produit déjà le résultat attendu.

No-code et low-code : de quoi parle-t-on exactement ?

Les termes se ressemblent, mais désignent deux approches différentes. Le no-code vise à permettre la création d’applications, d’automatisations, d’analyses ou de tableaux de bord sans écrire de code. L’utilisateur assemble généralement des éléments visuels, sélectionne des sources de données et définit des règles au moyen d’une interface.

Le low-code conserve cette logique d’assemblage, mais laisse une place à la programmation lorsque les composants disponibles ne suffisent plus. Il peut donc servir de pont entre les équipes métier et les développeurs, en combinant rapidité de conception et possibilité d’aller plus loin techniquement.

Dans les projets de données, ces outils peuvent servir à réaliser des analyses exploratoires, créer des visualisations, préparer des rapports automatisés ou tester une première idée de modèle prédictif. Leur intérêt principal est de réduire le délai entre une question et une première réponse exploitable. Ils favorisent aussi la réutilisation de certains processus sous forme de blocs ou de flux de travail, ce qui peut améliorer la collaboration entre équipes.

Cette accessibilité ne signifie pas que les outils font disparaître toute complexité. Il faut toujours savoir quelles données sont utilisées, comment elles ont été transformées, quels indicateurs sont calculés et ce qu’ils signifient. Une interface simple peut masquer des choix importants. C’est pourquoi la compréhension du contexte métier et des notions de base en données reste nécessaire, même sans programmation.

Pourquoi les équipes métier deviennent des acteurs de la donnée

Les outils accessibles sans code donnent davantage d’autonomie aux profils parfois appelés Citizen Data Analysts ou Citizen Developers. Ces collaborateurs travaillent au sein des fonctions métier, par exemple les ventes, le marketing, les ressources humaines ou la logistique. Ils connaissent souvent très précisément les besoins opérationnels, les indicateurs utiles et les situations qui posent problème au quotidien.

Lorsqu’ils peuvent transformer cette connaissance en tableau de bord, en rapport ou en prototype, les projets peuvent démarrer plus vite. Ils ne doivent plus attendre qu’une équipe technique disponible prenne en charge chaque demande simple. Cette autonomie est particulièrement utile pour explorer une idée, vérifier une tendance ou démontrer l’intérêt d’un projet avant d’engager des ressources plus importantes.

Mais l’autonomie ne doit pas être confondue avec l’isolement. Une équipe métier qui construit ses propres analyses a besoin d’un cadre commun : définitions partagées des indicateurs, accès aux bonnes données, règles de confidentialité et possibilité de solliciter des experts lorsque la question devient plus complexe. Sans cela, deux services peuvent produire des chiffres différents sur un même sujet, simplement parce qu’ils n’ont pas retenu les mêmes données ou les mêmes méthodes de calcul.

Le défi des DSI : favoriser l’innovation sans créer de Shadow IT

La montée du no-code et du low-code peut inquiéter les directions des systèmes d’information, ou DSI. Le risque le plus souvent cité est celui du Shadow IT : des outils, fichiers, automatisations ou applications sont utilisés en dehors des procédures et de la gouvernance prévues par l’organisation. Ces initiatives peuvent être utiles et partir d’un besoin concret, mais elles deviennent problématiques si personne ne sait quelles données elles utilisent, qui y accède ou comment elles sont maintenues.

Le rôle de la DSI ne consiste donc pas nécessairement à interdire les plateformes accessibles aux non-spécialistes. Il consiste à définir les conditions dans lesquelles elles peuvent être utilisées de manière sûre et durable. Cela implique notamment de choisir des environnements compatibles avec les règles internes, de gérer les droits d’accès, de suivre les opérations importantes et de préciser quels projets doivent être validés ou repris par des équipes techniques.

Les solutions no-code et low-code peuvent alléger une partie de la maintenance liée à un développement entièrement réalisé sur mesure. Elles n’éliminent pas pour autant la responsabilité de l’organisation. Les questions de sécurité, de confidentialité, de continuité de service et de dépendance à une plateforme doivent rester examinées avant le déploiement d’un outil.

Une gouvernance claire permet d’éviter deux écueils : bloquer des collaborateurs qui pourraient créer de la valeur rapidement, ou laisser se multiplier des solutions difficiles à sécuriser et à faire évoluer. Le bon équilibre passe souvent par une coopération continue entre métier, data scientists, développeurs et DSI.

L’IA générative abaisse une nouvelle barrière à l’entrée

L’arrivée de l’IA générative ajoute une couche supplémentaire à cette démocratisation. Par des instructions formulées en langage naturel, un utilisateur peut demander de l’aide pour créer un rapport, suggérer un workflow, rédiger une requête, générer une ébauche de code ou expliquer un résultat. L’interface devient plus conversationnelle et paraît moins technique.

Pour les équipes, l’intérêt est évident : des personnes qui ne maîtrisent pas les langages de programmation peuvent plus facilement passer de l’idée à un premier résultat. Les experts peuvent aussi accélérer certaines tâches répétitives, obtenir une première version de code ou documenter plus vite un processus. L’IA générative peut ainsi renforcer aussi bien les usages no-code que le travail des développeurs et des data scientists.

Il serait cependant risqué de considérer ces systèmes comme des décideurs autonomes. Une réponse bien formulée n’est pas une preuve de justesse. Toute analyse produite avec une assistance générative doit être confrontée aux données réelles, aux règles métier et aux objectifs du projet. De même, un workflow suggéré par une IA doit être vérifié avant d’être utilisé dans un contexte sensible.

L’IA générative déplace donc la compétence plutôt qu’elle ne l’efface. Savoir formuler une demande utile compte, mais savoir contrôler la réponse, repérer une incohérence et décider si le résultat est adapté compte davantage encore.

Ce qu’il faut surveiller pour choisir la bonne approche

La data science de 2024 ne se divise pas entre un monde ancien du code et un monde nouveau sans code. Elle devient un ensemble d’approches complémentaires. Le code reste la voie privilégiée lorsqu’il faut une personnalisation poussée, une logique complexe ou une industrialisation exigeante. Le no-code et le low-code répondent efficacement à de nombreux besoins d’analyse, de visualisation et de prototypage. L’IA générative, elle, rend les interfaces plus accessibles et peut accélérer le passage à l’action.

Le choix doit partir du problème à résoudre, et non de l’outil à adopter. Une première analyse peut être menée sans programmation, puis confiée à des spécialistes lorsqu’elle doit être fiabilisée, intégrée à des systèmes existants ou déployée à grande échelle. À l’inverse, tout projet ne mérite pas un développement sur mesure s’il peut être traité simplement et de façon sécurisée avec un outil visuel.

Les compétences les plus durables restent celles qui permettent de poser les bonnes questions : comprendre les données, mesurer les limites d’un résultat, collaborer avec les bons interlocuteurs et protéger les informations utilisées. Dans cet environnement mouvant, apprendre à coder demeure précieux. Apprendre à décider quand il faut coder l’est tout autant.