A quoi tient le fait que l’équipe data est si mystérieuse, voire opaque ?

4 raisons qui expliquent que personne ne sait vraiment ce qu’elle fait.

La data, c’est cet étranger familier que vous croisez tous les matins au portique de votre lieu de travail. Elle grimpe les marches de l’escalier 2 par 2, branche son mac à 2 écrans et même si elle adopte un style vestimentaire bien neutre c’est la seule à transporter ses affaires dans un sac à dos 25 litres.

Un jour votre regard s’est porté sur un de ses écrans en position verticale (quelle idée ?) et vous avez pris peur: sur fond noir apparaissaient des " SELECT * FROM bi_core.fact_employees " ou autres symboles qu’on aurait pu trouver 200 ans plus tôt sur la pierre de Rosette.

Après vous être sérieusement posé sur les raisons qui poussent une personne à écrire en lettres majuscules vous vous êtes demandé si vous aviez ici affaire à un développeur. Non, un développeur ne passerait pas la moitié de sa journée en meeting à parler avec la finance, le service client et.. parfois d’autres développeurs.

Vous êtes perdu.

C’est intriguant mais vous n’avez pas l’occasion de lui parler donc vous vous laissez porter par votre imagination. Et cela ne vous déplaît pas tellement en fin de compte, un peu de mystère ça pimente des après-midi un peu maussades.

Mais un beau jour tout change.

En sortant de l’ascenseur votre collègue mystérieux sort un peu trop brusquement la main de sa poche. Sa clef usb tombe à terre, c’est une clef usb Dark Vador. Votre sens de la justice vous titille, il faut l’avertir à tout prix.

“Salut, tu as laissé tomber ta clef usb Dark Vador”

“Ah merci, c’est ma clef usb Dark Vador. Au fait, enchanté je ne crois pas qu’on ait déjà parlé, moi c’est Nils !”

“Moi c’est Clémence, je suis dans l’équipe du service légal, tu fais quoi toi  ?”

“Je suis data analyst, rattaché à l’équipe produit.”

“Ah d’accord super.. ça veut dire quoi ?”

Aussi touchante que cette (vraie) histoire entre collègues peut être, elle vous illustre surtout que dans les faits la data est mal comprise. Et nous allons émettre aujourd’hui quelques hypothèses sur les raisons qui font que la data est ce département un peu plus opaque que les autres.

‍

La data c’est (plutôt) nouveau et très (très) divers

Les noms qu’on utilise pour décrire ces métiers sont plutôt nouveaux et relativement proches. C’est un peu comme si quelqu’un avait joué à créer des combinatoires d’anglicismes à partir des mots: data, engineer, analyst et scientist.

• Data Engineers
• Analytics Engineers
• Data Analysts
• Data Scientists

Cela dit ce n’est probablement pas la plus grande difficulté.

Le problème c’est que s’ils partagent la même mission mais que le contenu de leurs journées n’a souvent absolument rien à voir.

Prenons l’exemple du data-analyst et de tout ce qui peut entrer en compte dans la recette de son CV:

#1 Le département avec lequel vous collaborez qui dicte votre jargon et vos connaissances “métier”

Le vocabulaire que vous adoptez changera selon l’équipe avec qui vous travaillez; les connaissances requises et les parcours de vos interlocuteurs également.

Prenez l’exemple d’un Data analyst en produit qui interagit régulièrement avec des products managers ou des développeurs; pour lui, il sera utile d’avoir quelques bases ou au moins une culture en programmation pour comprendre un minimum les autres lors des réunions. Pour travailler avec l’équipe qui organise la sélection des visiteurs du site web pour les transformer en clients - “Growth” - il sera probablement plus utile de bien comprendre ce qu’est un funnel d’acquisition et la façon dont les cookies web fonctionnent.

#2 La taille et maturité de l’équipe qui détermine le spectre de vos tâches

Une idée qui ne vous étonnera pas: plus une équipe est grande plus les tâches de ses membres ont tendance à être spécifiques.

Si vous êtes le premier data-analyst tout d’abord félicitations, puis bon courage! En effet cela signifie que vous allez faire “de tout” dans un environnement à construire. Aujourd’hui on aurait tendance à l’appeler data analyst full stack, “full stack” par imitation au qualificatif de ces développeurs qui savent (presque) tout faire.

Plus tard, votre équipe data atteint une certaine taille et un seuil de maturité qui lui permet de répartir les tâches plus spécifiquement; votre mission se restreint désormais à un champs plus précis et on peut dire que le métier change car il y a certains pans que vous ne gérez plus.

Exemple concret: les data-engineers qui étaient au nombre de 2 vous autorisaient à valider du code sur github pour le mettre en production - dans les faits vous faisiez donc un peu de data-engineering, maintenant qu’il y a assez de data-engineers pour vous remplacer sur ces petites tâches à la frontière des deux, vous vous concentrez exclusivement sur vos analyses.

#3 Les préférences en termes d’outils

Exemple de stack data d’un SaaS

Il y a une myriade d’outils à la disposition du data-analyst. Et comme les tâches de votre quotidien et vos préférences sont différentes de l’un à l’autre, votre maitrise et temps passé sur tel ou tel outil sera très différent.

Concrètement, vous serez meilleurs sur Amplitude si votre équipe partenaire a besoin de mettre en place des trackers, qui sont des balises installées pour suivre les parcours utilisateurs. Si votre mission consiste à transformer des tables en SQL alors vous devrez plutôt maitriser dbt, s’il s’agit de visualisation alors Looker sera votre meilleur ami. Enfin parfois, certains data-analysts préféreront réaliser une analyse avec un Jupyter Notebook mais il est tout à fait possible d’utiliser la méthode excel pour une méthode plus traditionnelle.

#4 La technicité dont vous avez besoin pour remplir votre mission

Alors que certains data-analysts se doivent d’avoir un niveau en statistique ou SQL très élevé ce n’est pas le cas de tous ! En termes de technicité il y a autant de variabilité que dans n’importe quelles équipes et entreprises: ne soyez donc pas étonné si un data-analyst vous dit ne pas vraiment maitriser le cross join; c’est probablement qu’il n’en a jamais eu besoin.

Enfin naturellement, les responsabilité et l’impact varient d’un data-analyst à l’autre: quand pour l’un il s’agira de répondre aux questions opérationnelles et techniques des autres équipes, l’autre sautera de réunions en réunions pour comprendre les enjeux data autour du calcul du revenu  avec le CFO (directeur financier) et CEO.

‍

Le langage hermétique de la data érige une barrière qu’il faut surmonter.. et c’est le data-analyst qui possède l’échelle

La data est opaque car ses concepts préférés sont à la frontière de l’informatique, des statistiques et du management. On l’a évoqué rapidement, les mots de son quotidien sont variés et ne pas les maîtriser l’un ou l’autre érigera une barrière qui peut nuire à votre communication.

Pour l’illustrer, voici quelques termes communs que vous pourriez entendre lors d’une réunion:

• “test d’hypothèse” ou hypothesis testing : on utilise cette méthode statistique pour prouver que les différences qu’on trouve entre deux groupes statistiques ne sont pas imputables au hasard.
• “Integer”: en code c’est un format de donnée qui correspond tout simplement à un entier ! C’est utile pour compter les éléments indivisibles comme les clients. Avoir 4,5 clients c’est difficile concevable - pour cela on choisit donc de le représenter en entier.
• “Diagramme de Sankey”: en visualisation c’est très utile pour représenter des flux ou des répartitions par volume. On comprend bien plus rapidement que dans une matrice.

• “Payback Period”: en termes business on caractérise dans cette notion le temps qu’il faut pour rentabiliser l’investissement nécessaire à acquérir un client. On dira par exemple qu’au bout de 4 mois d’abonnement notre client “a remboursé” son coût d’acquisition.
• “Snowflake”: les data-engineers en raffolent car c’est un service de stockage et d'analyse de données basé sur le cloud qui a le vent en poupe depuis quelques années.

L’idée ici c’est que ces mots simples comme bonjour pour vous ne sont pas simples comme bonjour pour tout le monde. D’ailleurs, traduire ces concepts de manière efficace est le nerf de la guerre que mène le data-analyst quand il communique, c’est donc naturellement un facteur de succès, bien plus déterminant que le nombre de librairies python que vous maîtrisez.

N’oubliez cependant pas que vos parties-prenantes n’ont pas forcément besoin de savoir tout ce que vous savez, et d’ailleurs ne veulent pas vraiment le savoir.

Il est assez facile de concevoir qu’un développeur n’aura probablement que très peu d’intérêt pour la payback period d’un client et que le département marketing n’a pas forcément besoin de savoir ce que signifie integer. Pour la data-analyst cela dit les deux sont déterminants car un chiffre qui n’est pas dans le bon format donnera un mauvais résultat et la définition du payback exacte vous est cruciale pour bien écrire la formule.

En un mot on peut dire que les deux extrêmes - technique et business - vous concernent tandis que vos parties prenantes ne sont concernées que par l’un des deux.

La data est une équipe “support”: on peut l’ignorer si on en a pas besoin !

Ce qu’on connaît mal, c’est généralement ce qu’on côtoie le moins. Et il faut au moins avoir quelques exemples de cas d’usage pour comprendre ce dont il s’agit, car la théorie n’est pas évidente à comprendre. Bien souvent on pense que la data s’occupe uniquement de visualisations et de reportings, c’est évidemment très réducteur !

Au fil des interactions l’idée se précise, pensez aux déjeuners ou aux présentations personnelles en début de réunion pour creuser le sujet. Une fois qu’on a une idée de ce que l’équipe data peut nous apporter en automatisation et construction de KPIs, je peux vous assurer qu’on se met à voir des cas d’usages data partout.

Mais parfois on a aucune raison de s’adresser à la data !

Et c’est vrai: la data on en fait tous un peu, à notre sauce: dans le logiciel que vous utilisez tous les jours vous avez probablement des synthèses intégrées; ou dans un excel maintenu manuellement par les soins de votre équipe.

La data c’est parfois un travail fait dans l’ombre du business

Enfin la réalité c’est que la data vit un peu dans sa cave. Parfois elle en sort pour expliquer ce qu’elle fait quand les mots manquent aux représentants du business.

Par soucis de simplicité, les explications techniques sont raccourcies au profil des conclusions estimées plus importantes. Et c’est normal ! La data sert avant tout le business: une fois les métriques livrées elles sont appropriées par l’équipe cliente. Les ficelles passionnantes des flux de données et autres astuces techniques trouvées à la sueur de votre front n’intéressent probablement que les passionnés d’automatisation de calculs.

Quand vient le moment de communiquer l’équipe n’est donc pas forcément sollicitée, sa mission remplie elle attaque son prochain défi.

Conclusion

A l’époque où les inconnus jouaient leur sketch sur le langage hermétique il y avait l’avocat, le mécanicien.. mais s’ils devaient le refaire aujourd’hui ? On pourrait sans doute leur suggérer d’utiliser le data-analyst. Le vocabulaire anglicisé, ses concepts à la frontière de plusieurs domaines et sa passion pour les éléments techniques n’aident pas à lever le voile qui entoure son travail.

Une fois le voile levé cependant, la boîte noire qu’est notre équipe data devient pandore, et vous mettez à voir de la data partout. Soyez curieux et n’attendez pas qu’un collègue vous recommande la data pour oser parler de votre projet. Il se peut bien que votre cas d’usage entre parfaitement dans le champs du faisable pour la data.

Enfin si vous ne la voyez pas communiquer tant rappelez-vous que le business est roi en entreprise mais que ce n’est pas une raison pour affirmer qu’ils ne font rien.

Un proverbe Ovambo semble adéquat en guise de mot final: "Ne déprécie pas la tortue data à cause de son humilité, elle te guidera peut-être demain”.

‍