Leader un projet data : arbitrer, documenter, embarquer
Le rôle du lead technique data : arbitrer les choix d'architecture, les documenter en ADR courts, poser des standards et coordonner IT, data et métiers.
Un projet data réunit des gens qui ne parlent pas la même langue : l'IT pense sécurité et exploitation, les métiers pensent décision et délai, l'équipe data pense modèles et pipelines. Le lead technique data est la personne qui fait tenir ces trois mondes ensemble. Son travail se résume en trois verbes : arbitrer, documenter, embarquer.
Le rôle du lead technique data
Le lead technique n'est ni le chef de projet ni le meilleur développeur de l'équipe. Il est responsable de la cohérence technique de ce qui est livré, et de la capacité de l'équipe à le maintenir dans un an.
Sur le terrain, cela veut dire trancher quand deux options techniques sont possibles, rendre les décisions lisibles pour ceux qui arrivent après, et faire avancer métiers, IT et équipe data dans la même direction sans qu'ils se bloquent mutuellement.
Dans un contexte industriel, les données viennent de systèmes anciens, de capteurs, de fichiers de bureau d'études, d'un ERP (progiciel de gestion intégré) vieux de vingt ans, et les utilisateurs sont en atelier, en maintenance, en finance. Le lead technique doit comprendre suffisamment chaque monde pour que ses arbitrages soient acceptés par tous.
Arbitrer les choix d'architecture
Toute plateforme data repose sur une série de choix : où stocker, comment transformer, comment exposer, comment sécuriser. Chaque choix a des alternatives crédibles. L'erreur n'est pas de choisir une option plutôt qu'une autre ; c'est de ne pas choisir, ou de choisir sans dire pourquoi.
Un bon arbitrage suit une méthode simple : poser le contexte et les contraintes, lister deux ou trois options sérieuses (pas dix), les évaluer sur les critères qui comptent ici (coût d'exploitation, compétences disponibles, sécurité, réversibilité), trancher, puis écrire.
Quelques arbitrages typiques : historiser toutes les versions d'un référentiel ou seulement la dernière ; transformer les données dans l'entrepôt ou avant de les charger ; exposer un modèle sémantique unique ou laisser chaque outil de reporting faire ses calculs. Aucune de ces questions n'a de réponse universelle. Chacune mérite une décision explicite.
Documenter avec des ADR courts
L'ADR (Architecture Decision Record, ou registre de décision d'architecture) est l'outil le plus simple et le plus efficace pour rendre une décision durable. Un ADR tient sur une page et suit quatre rubriques :
- Contexte : le problème à résoudre et les contraintes du moment.
- Options : les alternatives envisagées, avec leurs avantages et inconvénients en deux lignes chacune.
- Décision : l'option retenue et la raison principale.
- Conséquences : ce que cela implique, y compris ce que l'on perd.
Un ADR se rédige le jour de la décision, pas trois mois après. Il est numéroté, versionné avec le code, et jamais effacé : si la décision change, un nouvel ADR remplace l'ancien. La personne qui découvre le projet dans deux ans comprend ainsi ce qui a été fait, pourquoi, et dans quelles conditions cela pourrait être remis en question.
Les ADR calment aussi les débats. Un choix documenté avec ses options et ses raisons ne se rouvre pas à chaque nouvelle arrivée dans l'équipe ; il se rouvre si le contexte a changé, et on le dit.
Poser des standards plutôt que des exceptions
Une plateforme data vieillit bien quand elle a peu de règles, connues de tous et appliquées partout. Elle vieillit mal quand chaque pipeline est une exception.
Les standards utiles sont peu nombreux : convention de nommage des tables et des colonnes, structure en couches (brute, préparée, exposée), tests de qualité obligatoires sur les clés et les valeurs nulles, revue de code avant mise en production, un seul endroit pour définir un indicateur. Ces règles s'écrivent en une page et se vérifient automatiquement quand c'est possible.
Le lead technique refuse les exceptions par défaut, parce que chaque exception est un futur incident que personne ne saura expliquer. Quand une exception est réellement nécessaire, elle fait l'objet d'un ADR : une décision assumée, pas un contournement oublié.
C'est précisément ce cadre qui permet ensuite d'accueillir l'IA. Un assistant fondé sur un LLM (grand modèle de langage) ou un agent connecté via un protocole comme MCP (Model Context Protocol) a besoin de données nommées de façon cohérente, documentées, et dont les droits d'accès sont connus. Sans standards, on ne sait pas ce que l'assistant va lire ni à qui il va le montrer. Avec des standards, on peut lui dire oui. La gouvernance n'est pas l'obstacle ; c'est la condition.
Coordonner IT, data et métiers
Trois équipes, trois rythmes. L'IT travaille en cycles de maintenance et de sécurité ; les métiers veulent des réponses avant le prochain comité ; l'équipe data itère en sprints, au sens des méthodes Agile.
Le lead technique organise les points de contact. Avec l'IT : les questions d'accès réseau, d'identité, de sauvegarde, de conformité, traitées en amont, jamais la veille d'une mise en production. Avec les métiers : la validation des chiffres en recette, la définition des indicateurs, et surtout la construction des droits.
Les droits d'accès aux données ne se conçoivent pas dans un bureau technique. Ils se construisent avec les métiers : qui doit voir quels sites, quels centres de coût, quelles personnes. Un contrôleur de gestion voit ses entités ; un responsable d'atelier voit ses lignes ; les données de salariés ne sortent pas de la direction des ressources humaines sans base légale au sens du RGPD (règlement général sur la protection des données). Écrites avec les métiers, ces règles deviennent des règles de sécurité par ligne dans la plateforme et dans les outils de reporting, vérifiables et auditables.
Transmettre et gérer la dette technique
Un lead technique qui garde tout dans sa tête est un risque pour le projet. La transmission fait partie du rôle : revues de code commentées, binômage sur les sujets difficiles, documentation vivante, sessions courtes où l'on explique un ADR ou un pipeline à l'équipe.
La dette technique se nomme, se liste et se priorise. Chaque raccourci pris pour tenir un délai est noté avec sa raison et son coût estimé. Une part de chaque cycle lui est consacrée. Une dette invisible se rappelle toujours au pire moment, souvent lors d'un changement de système source ou d'une demande d'audit.
Les signaux d'un projet qui dérive
Quelques signes qui doivent alerter le lead technique, et le sponsor avec lui :
- les décisions se prennent en réunion et ne sont écrites nulle part ;
- chaque nouveau pipeline a sa propre convention ;
- la recette est sautée « pour cette fois » de plus en plus souvent ;
- deux tableaux de bord donnent des chiffres différents pour le même indicateur ;
- les métiers demandent des extractions plutôt que d'utiliser la plateforme ;
- la liste de la dette technique n'a pas bougé depuis des mois ;
- les questions de droits d'accès sont reportées « à plus tard ».
Aucun de ces signaux n'est fatal. Tous sont réversibles si on les voit tôt.
À retenir
- Le lead technique data répond de la cohérence technique et de la maintenabilité, pas seulement de la livraison.
- Toute décision d'architecture mérite un ADR d'une page : contexte, options, décision, conséquences.
- Peu de standards, connus de tous, valent mieux qu'une collection d'exceptions.
- Les droits d'accès se construisent avec les métiers et se traduisent en règles vérifiables.
- La dette technique se nomme, se liste et se traite à chaque cycle.
- Des données nommées, documentées et protégées sont ce qui permet de dire oui à l'IA.
Checklist
- Chaque décision d'architecture a un ADR daté et versionné avec le code.
- Les conventions de nommage et la structure en couches tiennent sur une page.
- Les tests de qualité sont automatiques sur les clés et les valeurs obligatoires.
- Les règles d'accès ont été écrites avec les métiers et appliquées par ligne.
- Les données personnelles sont identifiées et leur base légale est documentée.
- La liste de la dette technique est à jour et une part de chaque cycle lui est réservée.
- Les points de synchronisation avec l'IT et les métiers ont une fréquence fixe.