Où part vraiment votre budget d’ingénierie ?
En mars, Fivetran a publié une étude menée auprès de 500 dirigeants data et technologie, dans des entreprises de plus de 5 000 salariés. On en a retenu un chiffre : 53 % de la capacité d’ingénierie part dans la maintenance et le dépannage des pipelines. Et près de 97 % de ces dirigeants disent que des pannes de pipelines ont ralenti leurs programmes d’analyse ou d’IA.
Il faut le prendre avec des pincettes. Fivetran vend des pipelines gérés, et sa conclusion va, sans surprise, dans ce sens. C’est aussi une enquête déclarative : des dirigeants estiment, personne n’a chronométré. dbt Labs ne donne pas de pourcentage dans son rapport publié en avril, mais une majorité de ses répondants disent passer l’essentiel de leur temps à maintenir ou organiser des jeux de données.
Même comme simple ordre de grandeur, la moitié d’une équipe qualifiée, ça pose question. Qu’est-ce qu’elle fait, cette moitié ? Et est-ce qu’elle doit vraiment le faire ?
Sur un projet d’intégration d’une plateforme à forte volumétrie, la règle métier tenait en quelques lignes, mais le raccordement entre les deux ERP a pris trois semaines : formats, authentification, relances, pagination. Dans la même veine (ou manque de) un pipeline a tourné plusieurs jours en produisant des données erronées, sans la moindre erreur. L’émetteur envoyait des tableaux JSON, quand le récepteur attendait du JSON Lines. Aucun des deux outils n’était en faute, et personne ne surveillait la jonction.
Une partie, c’est le métier
Tout n’est pas à jeter dans ces 53 %. Un fournisseur modifie son API, un système source renomme un champ, une réglementation change une durée de conservation : il faut suivre. C’est le rôle d’une équipe data, et aucune architecture ne fera disparaître ça.
Le reste, on en parle beaucoup moins en dehors des équipes. Ce sont les relances quand un appel échoue, les délais d’expiration réglés un jour et jamais revus, les conversions de format entre deux outils internes, les identifiants passés à la main, la gestion d’erreurs qui avale un échec à un endroit pour le laisser ressortir trois étapes plus loin, et tous ces adaptateurs écrits pour que ce que produit un outil soit accepté par le suivant.
Les équipes appellent ça de la plomberie. Elle est écrite par la personne la plus proche du ticket, souvent en fin de sprint. On la relit peu, parce qu’elle a l’air secondaire. On la teste encore moins, parce que la tester demande de faire tourner deux systèmes en même temps. Et pourtant, beaucoup d’incidents viennent de là : une panne qui survient entre deux composants n’appartient à aucun des deux, et personne ne la surveille vraiment.
D’où vient cette plomberie
Personne n’a décidé d’écrire toute cette plomberie. Elle est là parce que nos outils n’ont aucune idée commune de ce qu’est une connexion.
Prenez un socle data classique : un outil d’ingestion, un orchestrateur, un outil de transformation, un entrepôt de données, souvent un bus de messages, un outil de qualité, un catalogue. Chacun fait très bien son travail. Mais aucun ne partage avec les autres une définition de ce que veut dire « passer des données au suivant ». Alors à chaque jonction il faut un contrat, et ce contrat, quelqu’un l’écrit dans le code, sans typage, sans vérification, souvent sans même en garder une trace.
C’est aussi pour ça que les leviers habituels marchent mal. Recruter, ajouter du process ou rationaliser les outils, ça revient à écrire la même plomberie avec plus de monde, avec plus de relectures, ou dans un autre format. Et l’assistant de code ? Il l’écrit plus vite. Sauf que taper le code n’a jamais été le plus coûteux. Le plus coûteux, c’est de savoir si la jonction tient.
Côté livraison logicielle, même problème
Si vous êtes plutôt côté développement que côté data, vous avez déjà un cousin de ce problème à la maison. Lancez ceci dans votre dépôt principal :
git log --oneline | grep -ciE "fix.*\bci\b"
Ce nombre, ce sont les commits faits pour réparer la chaîne d’intégration continue, pas le produit. Chacun correspond à un aller-retour bien connu : on pousse, on attend quelques minutes, ça casse, on corrige, on repousse. Parce qu’une CI, personne ne sait vraiment la faire tourner à l’identique sur son poste.
Au départ, une configuration de CI, c’était une liste de commandes. Puis sont arrivés les conditions, les boucles, les templates, les variables… C’est devenu un langage de programmation, mais sans typage, sans exécution locale, et sans aucun moyen de savoir qu’une modification est fausse avant d’avoir payé pour l’exécuter.
Ce qui peut vraiment faire bouger ce chiffre
Il n’y a pas trente-six solutions : il faut que la connexion entre deux composants devienne quelque chose que le système comprend, au lieu d’être réinventée par l’équipe à chaque jonction.
Concrètement, le passage de données d’une étape à l’autre doit avoir une forme déclarée, et quelque chose doit vérifier que les deux côtés sont d’accord avant de lancer quoi que ce soit (plutôt qu’à trois heures du matin, une fois qu’ils ont divergé). Les relances, la remontée des erreurs et la régulation des flux doivent être gérées par la couche du dessous, pas par la personne qui a écrit telle ou telle jonction. Et une étape qui doit partir sur une autre machine doit pouvoir y partir sans être réécrite.
On ne va pas faire semblant d’être neutres : c’est exactement ce qu’on construit chez Mélodium. Comme Fivetran, on a donc un intérêt dans ce diagnostic. C’est pour ça que la suite est une mesure que vous pouvez faire sans nous, et sans eux.
Mesurer votre propre chiffre en un après-midi
Prenez votre pipeline ou votre intégration la plus importante, et les vingt dernières modifications qui y ont été fusionnées (ou les tickets du dernier trimestre, si c’est plus simple). Demandez à deux personnes de les classer chacune de leur côté, puis comparez. Là où elles ne sont pas d’accord, il y a déjà quelque chose à apprendre.
Trois catégories :
- Ce que le métier a demandé. Une nouvelle source, un nouvel indicateur, une nouvelle règle, une demande venue d’en dehors de l’équipe.
- Ce que le monde extérieur a imposé. Un fournisseur a changé son API, un système source a changé de schéma, une réglementation a évolué.
- Ce que vos propres outils ont imposé. Deux de vos outils ne s’entendaient pas, une relance ou un délai a été réajusté, un format a été converti entre deux composants internes, un identifiant a été géré à la main, ou une panne est survenue entre deux étapes plutôt que dans l’une d’elles.
La première catégorie, c’est de l’investissement. La deuxième, c’est le prix à payer pour exister dans le monde réel, et ça se gère avec les fournisseurs et les contrats. La troisième, c’est la plomberie dont on parle ici. Si elle pèse plus lourd que la première, votre architecture occupe davantage votre équipe que votre feuille de route.
Pour passer en euros : part de la troisième catégorie × nombre d’ingénieurs × coût complet annuel. Un exemple, avec des chiffres inventés pour l’occasion : huit ingénieurs à 90 000 euros de coût complet et une troisième catégorie à 35 %, ça fait 252 000 euros par an passés sur les jonctions entre vos propres outils. Mettez les vôtres.
Trois décisions, sans rien acheter
Quel que soit votre résultat, il y a trois choses à faire qui ne demandent aucun fournisseur.
D’abord, refaire la mesure. Tous les trimestres, même classement, et la troisième catégorie présentée dans la même revue que les dépenses cloud. On suit la facture cloud à l’euro près, alors que ce chiffre-là, presque personne ne le mesure.
Ensuite, compter les jonctions à chaque choix d’outil. Chaque produit ajouté au socle crée des connexions que quelqu’un devra maintenir. « Combien de jonctions en plus, et qui s’en occupe ? » a sa place dans chaque revue d’architecture et chaque achat, juste à côté du prix de la licence.
Enfin, s’attaquer à la pire jonction plutôt qu’à toute la plateforme. Prenez celle qui a généré le plus de modifications de troisième catégorie et le plus d’incidents, et traitez-la comme un vrai projet, avec quelqu’un de responsable et un budget, pas comme un bruit de fond qu’on subit.
53 %, c’est l’estimation de Fivetran. Chez vous, c’est peut-être moins, peut-être bien plus. Si vous faites l’exercice, on est vraiment curieux de savoir ce que ça donne.
Sources
- Fivetran, The Enterprise Data Infrastructure Benchmark Report 2026, publié le 26 mars 2026. Enquête menée au quatrième trimestre 2025 auprès de 500 dirigeants data et technologie d’entreprises de plus de 5 000 salariés. Communiqué , rapport .
- dbt Labs, 2026 State of Analytics Engineering Report, publié le 10 avril 2026. Rapport .