Un responsable marketing m'a montré, fier, un tableau de bord monté en une après-midi. Il avait décrit ce qu'il voulait à un outil d'IA, le code était sorti tout seul, le dashboard tournait. « Plus besoin de la data team », a-t-il lâché à moitié pour rire.
Trois semaines plus tard, l'équipe data passait deux semaines pleines à réparer derrière lui. Les chiffres ne tombaient pas juste. Personne ne savait d'où venait un agrégat. Le tableau de bord marchait, oui. Il avait juste tort.
Cette scène résume tout ce qu'il faut comprendre du vibe coding quand on fait de la data. Ce n'est ni la fin du métier, ni un gadget. C'est un déplacement, et il vaut mieux savoir dans quel sens.
Le vibe coding, en clair
Le terme vient d'Andrej Karpathy, l'un des informaticiens connus du domaine de l'IA. L'idée tient en une phrase : tu décris ce que tu veux en langage naturel, un modèle d'IA écrit le code à ta place. Le dictionnaire Collins en a fait son mot de l'année 2025, ce qui dit surtout que la pratique est sortie du cercle des développeurs.
La règle implicite du vibe coding, c'est que le succès se juge à « est-ce que ça marche ? ». On ne relit pas forcément le code ligne à ligne. S'il tourne et produit un résultat, on avance.
Pour beaucoup de métiers, c'est une libération. Un marketeur prototype un mini-outil, un product manager teste une idée sans mobiliser un ingénieur. Pour le travail data, cette règle du « ça marche » est précisément le piège.
Pourquoi « ça marche » ne veut rien dire en data
Voilà le problème de fond. Dans une application classique, un bug se voit : la page plante, le bouton ne répond pas, l'utilisateur râle. L'erreur est bruyante.
En data, l'erreur est silencieuse. Une requête SQL mal jointe ne plante pas. Elle renvoie un résultat. Un résultat faux, mais propre, aligné, exportable. Un `LEFT JOIN` qui aurait dû être un `INNER JOIN` double discrètement ton chiffre d'affaires. Une granularité mal pensée et ta moyenne devient un non-sens. Rien ne hurle. Le tableau de bord s'affiche.
C'est là que le vibe coding tel quel se casse la figure sur la donnée. L'IA te donnera une requête qui s'exécute. Elle ne te dira pas que la table de faits a des doublons, que le fuseau horaire change le résultat, que cette colonne est nulle une fois sur dix depuis la migration de mars. Elle code la demande, pas le contexte.
L'analytics engineer, lui, vit dans ce contexte. C'est tout son métier.
Ce que le vibe coding fait vraiment bien pour la data
Ne jetons rien. Bien utilisé, l'IA générative est un excellent collègue junior, rapide et infatigable, pour une partie réelle du travail.
Le boilerplate, d'abord. Un modèle dbt de staging qui renomme et caste trente colonnes, c'est mécanique et pénible. Le décrire et le faire générer fait gagner un temps net.
Le débogage de syntaxe, ensuite. Une regex tordue, une fonction de fenêtrage dont tu ne retrouves jamais l'ordre des arguments, une erreur de l'adaptateur dbt incompréhensible. L'IA déblaie ça en quelques secondes.
Le prototype jetable, enfin. Tu veux vérifier une hypothèse avant d'investir dans un vrai modèle ? Décris, génère, regarde, jette. Tant que le code finit à la poubelle, le « ça marche » suffit largement.
Sur une mission récente, un analytics engineer de l'équipe générait ses tests dbt de base par lot avec un assistant IA, puis passait son temps de cerveau sur les tests métier, ceux qui demandent de connaître l'entreprise. Bon usage. Il n'avait pas délégué le jugement, il avait délégué la frappe.
Ce que ton métier devient
Voilà le déplacement. Pendant longtemps, une partie de la valeur d'un data analyst ou d'un analytics engineer tenait à une compétence rare : savoir écrire du SQL correct, vite. Cette compétence ne disparaît pas, mais elle se banalise. La machine tape vite, elle aussi.
Ce qui ne se banalise pas, c'est tout le reste. Savoir quelle est la bonne granularité d'une table. Savoir qu'un chiffre est suspect avant même de l'avoir vérifié. Savoir écrire le test qui attrapera l'erreur dans six mois. Savoir dire non à une demande mal posée et reformuler la vraie question.
Le vibe coding ne supprime pas l'analytics engineer. Il déplace son centre de gravité. Moins de temps à produire du code, plus de temps à garantir qu'il est juste, testé, documenté, maintenable. Autrement dit : le métier devient encore plus celui de la rigueur et de la modélisation, et un peu moins celui de la dactylo SQL.
C'est plutôt une bonne nouvelle. La partie pénible part vers la machine. La partie intéressante, celle du raisonnement, prend toute la place.
Les compétences qui prennent de la valeur
Si le code se génère, sur quoi miser ?
La modélisation des données, en premier. Comprendre Kimball, savoir poser une table de faits propre, choisir une granularité : ça, aucun prompt ne le fait à ta place, parce que ça dépend du métier.
Les tests, ensuite. Un analytics engineer qui sait écrire les bons tests dbt, ceux qui valident une règle métier et pas juste l'absence de nulls, devient le filet de sécurité de toute l'équipe. Plus on génère de code vite, plus ce filet vaut cher.
La revue de code, aussi. Relire du code, repérer ce qui cloche, comprendre une logique qu'on n'a pas écrite : cette compétence longtemps réservée aux seniors devient indispensable à tous. Quand l'IA écrit, quelqu'un doit relire. Ce quelqu'un, c'est toi.
Et le prompt clair, enfin. Pas une mode : savoir décrire précisément un besoin, avec son contexte, ses contraintes, ses cas limites, c'est exactement la même compétence que rédiger une bonne spec. Ceux qui prompto bien sont ceux qui pensaient déjà clairement avant l'IA.
Le vrai risque, et il n'est pas technique
Le danger n'est pas que l'IA écrive du mauvais code. C'est qu'elle écrive du code plausible que personne dans l'équipe ne comprend.
Une équipe data qui accepte du SQL généré sans le relire accumule une dette invisible. Le jour où un modèle casse, personne ne sait le réparer, parce que personne ne l'a jamais vraiment lu. Tu te retrouves mainteneur d'un code orphelin, écrit par une machine, validé par personne.
La règle saine est simple. Tout code qui part en production est relu et compris par un humain de l'équipe, qu'il sorte d'un cerveau ou d'un modèle. Le vibe coding est autorisé pour prototyper et pour brouillonner. Il s'arrête à la porte de la production, où reprennent la revue, les tests et la documentation.
Ce que tu fais cette semaine
Ne fuis pas l'IA, et ne lui délègue pas ton jugement. Fais trois choses concrètes.
D'abord, prends une tâche vraiment mécanique de ta semaine, un modèle de staging, un lot de tests de base, et fais-la générer. Mesure le temps gagné. Ce temps, réinvestis-le dans la partie métier.
Ensuite, prends un bout de SQL généré par une IA et relis-le comme un reviewer exigeant. Cherche le `JOIN` qui double les lignes, la granularité douteuse, le filtre manquant. Entraîne ce muscle-là, c'est lui qui te rendra irremplaçable.
Enfin, écris un prompt comme tu écrirais une spec : le besoin, le contexte des données, les cas limites, la définition de « correct ». Tu verras que la qualité de la réponse suit la qualité de la question.
Le vibe coding ne remplacera pas l'analytics engineer. Il remplacera l'analytics engineer qui ne faisait que taper du SQL. Ce n'est pas la même phrase, et toute ta carrière tient dans la différence.
