La stratégie de l’échec d’un projet data

Qu’est-ce qui fait la réussite ou l’échec de nos projets data ? À quel point avons-nous le contrôle sur la direction que va prendre notre projet ? Prend-on à un moment l’embranchement qui nous mènera inéluctablement vers l’une ou l’autre issue extrême qui nous est dévolue ?

Cet article n’est pas un article comme les autres. C’est une expérience à vivre et à pratiquer, parce que l’échec est une philosophie de vie, un art dont nous allons ici tenter de percer les secrets, en nous intéressant tout d’abord aux aspects qui peuvent s’appliquer à tout type de projets, pour ensuite nous focaliser sur ceux spécifiques à la data.

Les points de contrôle de l’échec

Ce qui n’est pas spécifique à la data

• Pas de plan

Le premier conseil à suivre pour échouer avec panache est relativement simple : naviguer à vue. Quel que soit le type de projet, se passer d’une planification est un excellent moyen de prendre un maximum de risques quant au déroulement du projet.

D’une part, parce que vous évitez d’avoir recours à un support visuel qui pourrait mettre en évidence les responsabilités, les risques, les incohérences ou la mauvaise répartition des charges. D’autre part, parce que vous vous passez d’un très puissant support de discussion avec toutes les parties prenantes.

Alterner les périodes de saturation et les périodes de calme, se soumettre à une variabilité incontrôlable. Être inconscient de l’efficacité du fonctionnement de l’équipe sur sa cadence. Découvrir un retard dans la dernière ligne droite d’un projet. Voilà d’excellents moyens de vous éloigner de la voie du succès.

Par effet boule de neige, vous pouvez espérer l’ajout de réunions de crise et de task forces qui ne manqueront pas d’épuiser l’équipe et de casser l’ambiance.

Si tout le succès d’une opération réside dans sa préparation, l’échec d’un projet réside dans sa non préparation. Tout le talent et la persévérance du monde auront peu de chance de contrecarrer le mécanisme menant au fiasco d’un projet non préparé.

Selon la phrase attribuée à Benjamin Franklin : “Celui qui échoue à planifier, planifie son échec.”

Les embûches : des discussions régulières autour d’un document de type macro-plan vous priveraient des effets de surprise emplis d’émotions, des déceptions engendrées par des échéances encore décalées et des moments de panique face au jalon qui pointe le bout de son nez. Comment s’assurer de répéter encore et encore les mêmes erreurs lorsqu’un macro-plan se glisse entre votre stakeholder et vous ? Le Kanban board est, quant à lui, un révélateur de retard à une échelle plus fine, qui risque de laisser l’équipe réagir par anticipation et éviter les retards.

• S’en tenir au plan

  Admettons que vous ayez déjà un plan et que vous deviez faire une croix sur l’idée du paragraphe précédent -pas de plan-. Vous pouvez tout aussi bien échouer en optant pour la stratégie inverse : vous conformer au plan coûte que coûte. En effet, le plan est un outil et vous détenez le pouvoir de l’utiliser comme bon vous semble, pour le meilleur et pour le pire…

  Restez donc inflexible, imperméable aux aléas du projet et fidèle à vos convictions d’origine. C’est la meilleure manière d’entamer une marche forcée dirigée droit vers le mur. Étant donné que vous oeuvrez totalement pour conserver le même contenu et les mêmes jalons, votre seule variable d’ajustement sera la qualité et vous vous assurez de récolter la déception des utilisateurs et de l’équipe de développement.

  Les embûches : un fonctionnement par sprint dont l’objectif et le contenu reposent sur un backlog de fonctionnalités priorisé. Une approche “inspect & adapt”, permettant d’ajuster au fur et à mesure. Une remise en question continue de la stratégie et de la valeur ajoutée en bout de chaîne. Là encore, des discussions régulières autour d’un document de type macro-plan, permettant d’ajuster la stratégie.

• Construire sans connaître l’usage

  Vous devrez construire en vous fiant à votre intuition, indépendamment de la façon dont les utilisateurs feront appel à votre produit. Imaginons un produit qui remplit la bonne fonction, mais sans prendre en compte les conditions d’utilisation -dans quel contexte, dans quelles conditions, avec quelle répétition ?- Par exemple, ne pas prendre en compte le fait que le produit devra résister à l’eau de mer, au froid, subir des forces de torsion ou encore être utilisé dans l’obscurité.

  Si vous négligez la prise en compte de l’usage, vous pouvez donc rendre inutilisable un produit pourtant a priori adapté au besoin, et tendre les bras à l’échec malgré une spécification claire et parfaitement comprise. C’est un sujet que maîtrisent, entre autres, les experts de l’expérience utilisateur.

  En termes de projet data, le point critique se situe alors essentiellement au niveau du modèle de données. C’est là que se trouve la faille à exploiter pour prendre le chemin de la déroute. Le modèle de données se forge autour du besoin : d’une part de la façon dont on ira chercher la donnée pour la présenter à l’utilisateur, et d’autre part en fonction de la manière dont on a besoin d’alimenter les tables.

  Par exemple, vous pouvez opter pour la philosophie du “qui peut le plus peut le moins” et mettre en place un modèle générique semi-structuré utilisant des champs imbriqués. Dans un contexte à forte volumétrie avec un besoin de simplicité et d’efficacité, vous allez favoriser l’apparition de complexités et de problèmes de performance qui pourront devenir rédhibitoires.

  Ne pas bien connaître l’usage, c’est jouer à la roulette russe au moment d’établir le modèle physique, de mettre en place des indexes ou encore de choisir comment clusteriser des tables.

  Les embûches : le suivi de la satisfaction client. Il est bien plus évident de fournir un produit inadéquat lorsqu’on ne prend pas en compte les retours utilisateur.

• Pas de documentation

  C’est bien connu : implémenter un projet sans le documenter est redoutablement efficace dans l’optique d’échouer. Pour rendre la maintenance hasardeuse grâce à l’absence de documentation technique. Pour plonger l’utilisateur dans un univers mystérieux.

  En termes de data, les indicateurs sont sujets à interprétation. De quelle formule de chiffre d’affaires me parles-tu parmi les 9 que je connais ? Sommes nous sur des comparaisons à périmètres comparables ? Parles t-on d’années glissantes ? De périodes échues ? De référentiel à vision courante ou historisée ? Quels événements a-t-on choisi de filtrer ? De dé-dupliquer ? Quand les données ont-elles été mises à jour ?

  Ne partagez pas le modèle de données, laissez les gens deviner les relations entre les tables. Les escapes games ne sont-ils pas à la mode ? Vous pouvez même aller un cran plus loin en choisissant des noms de tables et de colonnes sans norme, ambigus, obscurs, incomplets, dans différentes langues, voire trompeurs. Qui n’a jamais rencontré le creation_date qui est en fait un timestamp, la colonne nommée jklsg90, le contract_id qui n’est pas un identifiant, le address qui correspond à la ville ou encore le store qui correspond à un magasin… ou éventuellement à un entrepôt ?

  Les embûches : esquivez également les data catalogs. En décrivant la nature de la donnée mais aussi son usage, sa traçabilité, ces outils réduisent drastiquement les chances de semer le doute et la perplexité chez l’utilisateur.

• Le choix des outils (Cool data stack)

  Choisir un outil ou une technologie pour son projet peut être encore une occasion d’échouer. Optez donc pour un outil dont vous avez entendu parler, imposez le sans écouter les avis divergents, suivez les tendances. Vous aurez la possibilité de prendre le mauvais outil, ou le bon mais pour de mauvaises raisons ou de la mauvaise manière. Considérez que la technologie est une fin et non un moyen afin de semer les embûches sur votre chemin.

  Pour traiter et stocker vos données, vous aurez besoin d’une infrastructure digne de ce nom et au temps de la modern data stack le choix est vaste. La modern data stack est l’association d’outils d’ingestion, de transformation, de stockage, d’orchestration, de visualisation, de gouvernance, de contrôle qualité de la données. Autant de possibilité de prendre des outils qui ne sont pas adaptés ou pas compatibles.

  Les embûches : chez Sicara, nous faisons systématiquement appel aux ADR : Architecture Decision Record. Cela consiste à comparer un nombre restreint d’outils candidats pour accomplir une tâche particulière et de les évaluer en fonction de critères de décision. Difficile dans ces conditions de faire le choix irréfléchi, il vous faudra les ignorer pour vous conformer à la stratégie de l’échec.

• Qu’importe l’équipe

  Une équipe en sous-effectif ou en sureffectif est dans les bonnes conditions pour rater un projet. Une personne seule, qui pourra se retrouver surchargée, qui ne pourra pas faire challenger ses choix, discuter de ses difficultés ou de ce qu’elle est en train de mettre en place, aura toutes les chances de bloquer et de faire des erreurs. À l’inverse, une équipe nombreuse, généralement au-delà de 6 à 8 personnes, commencera à rencontrer des problèmes de communication, de synchronisation, d’inertie. L’erreur qui consiste à ajouter des membres d’équipe pour avancer plus vite, sans avoir préalablement cherché à comprendre le pourquoi de la vélocité actuelle de l’équipe reste un classique du genre.

  Par ailleurs, étant donné que c’est l’équipe qui fait vivre le projet, négliger ses membres, leur environnement de travail, leur possibilités d’apprendre et de progresser, aura un impact négatif sur le projet. Ne leur donnez pas de responsabilité et un minimum de visibilité, micro managez les, considérez les comme des exécutants. Vous obtiendrez des résultats spectaculaires.

  Cela s’applique de la même manière aux projets data qu’aux autres types de projets.

  Les embûches : des équipes structurées, avec un leader technique assurant le point de départ d’une chaîne d’entraide, veillant à ce que chacun progresse et travaille dans les meilleures conditions possibles. Des membres d’équipe qui ont des responsabilités claires, communiquent, définissent des stratégies techniques et se synchronisent dans des “daily meetings”

Ce qui est spécifique aux projets data

• Mauvaise qualité de donnée

  Une mauvaise hygiène de vie vous apporte une mauvaise santé. Fournir de la donnée de mauvaise qualité à votre projet, c’est un peu comme suivre un régime à base de verres d’huile d’arachide et laisse peu de doute sur le résultat.

  Mais tout d’abord, rappelons brièvement en quoi consiste la qualité de donnée. On peut tout d’abord la résumer avec les 5 critères suivant :

  • Unicité : pas de doublons
  • Complétude : la donnée n’est pas partielle et couvre bien le périmètre attendu
  • Exactitude : elle représente bien la réalité
  • Fraîcheur : elle est à jour
  • Validité : elle respecte les bons formats et plages de valeurs prévues

  Auxquels on peut ajouter ces deux autres :

  • Cohérence : elle ne se contredit pas dans les différents datasets de l’entreprise
  • Intégrité : elle n’est pas détériorée au cours de son cycle de vie

  La mauvaise qualité de données est une valeur sure, garante de l’échec d’une grande partie des projets data, causant des millions d’euros de pertes et grevant massivement les bénéfices des entreprises, comme le décrit Chloé Caron dans cet article. 

  La meilleure partie, c’est qu’aucune action particulière n’est à mener, vous pouvez vous installer confortablement et observer le phénomène opérer. Considérons maintenant qu’à un instant t, vous recevez uniquement des données d’une qualité irréprochable. Tout n’est pas perdu pour autant ! Si vous vous abstenez de contrôler la qualité régulièrement, vous conservez toujours de grandes chances que des modifications effectuées en amont viennent semer le chaos dans votre système.

  Délivrez des informations inexactes ou inexploitables à vos utilisateurs, vous obtiendrez une perte de confiance qui pourrait mener à l’abandon pur et simple du projet.

  Les embûches : le contrôle de la qualité. Pour en savoir plus, découvrez l’article de Lucie Martin sur la Data Quality with Sifflet 

  Les “data contracts” constituent également une embûche, mais nous y reviendrons plus tard
  
  

• L’opulence de données : RGPD !

  En parlant d’hygiène de vie, gaver les utilisateurs de données peut aussi être un bon moyen de couler un projet data. Tout d’abord parce que l’opulence ajoute inévitablement de la complexité et il sera forcément plus difficile de s’y retrouver dans un océan de données dix fois plus vaste. La complexité excessive et inutile est un excellent moyen de semer le trouble au sein de l’équipe, de ralentir le rendement et de plonger vos utilisateurs dans la plus grande confusion.

  On vous opposerait en plus bien peu de résistance si vous interrogiez vos utilisateurs. Après tout, qui peut le plus peut le moins et qui se plaindrait d’avoir accès à un choix pléthorique de données et s’ouvrir à des opportunités encore inconnues ? Nous sommes dans l’ère du Big data, voyez grand, profitez-en !

  Voilà une occasion en or de croiser sur son chemin les exigences du règlement général sur la Protection des Données (RGPD). Ouvrez donc les vannes et le délégué à la protection des données (DPO) de votre entreprise vous tombera dessus à juste titre. Vous l’aurez compris vos soucis seront moins liés au règlement qu’à votre incapacité à gouverner vos propres données. Cerise sur le gâteau, en ratissant suffisamment large, vous aurez probablement récupéré des données personnelles identifiables ou en Anglais personal identifiable information (PII), qui, si elles ne sont pas traitées en conséquence pourront vous mener à des sanctions financières et apporter le coût de grâce à votre projet. Vous pouvez aussi recopier et disséminer vos données dans une multitude d’endroits différents afin de créer un jeu de piste qui viendra à bout des utilisateurs les plus persévérants : qui devinera la source de vérité quand on peut trouver la donnée dans 3 tables différentes ? Enfin, l’opulence peut aussi être liée à la durée de rétention de vos données. Gardez-les donc indéfiniment, pour augmenter les coûts de stockage, ralentir les performances, et là encore risquer des sanctions RGPD.

  Les embûches : le minimalisme consistant à ne récupérer que strictement ce dont on a besoin. Être capable de justifier la nécessité de chaque élément collecté.

  Gérer le cycle de vie des données et mettre en place des purges de données

  Utiliser un outil de gouvernance

• Le verrouillage des données

  D’un extrême à l’autre, vous pouvez tout aussi bien cadenasser l’accès à outrance, sans raison valable, c’est-à-dire que nous ne parlons pas ici de restrictions liées à la confidentialité des données, ce que personne ne saurait vous reprocher. Non, nous parlons ici de donner un minimum de liberté et de possibilités à vos utilisateurs.

  Offrez leur un accès à des données agrégées, avec des indicateurs que vous aurez calculés de votre côté d’après des spécifications et vous deviendrez un redoutable goulot d’étranglement.

  Attention, ce dispositif ne fonctionne pas dans tous les cas. Cela dépend de la taille de l’entreprise, de la maturité sur l’utilisation de la donnée, du métier et des besoins des utilisateurs. La recette idéale se déroule comme suit :

  • une équipe data centralisée, au milieu de divers départements
  • des utilisateurs à qui on demande de spécifier des indicateurs d’après leur vision du moment
  • l’équipe data construit le produit de sont côté pendant plusieurs semaines, voire plusieurs mois
  • les utilisateurs ont accès aux données mais le besoin ou la compréhension de celui-ci a pu changer depuis

  D’une manière générale, offrez à vos utilisateurs un système rigide et limité qui se traduira en un accès inadapté aux données, à un taux d’adoption faible et à des utilisateurs mécontents.

  Les embûches : un self-service documenté. Des évangélisateurs de type data stewards pour diffuser une bonne utilisation des données dans l’entreprise

• Le mauvaise interfaçage et l’absence de “data contract”

  La mauvaise qualité d’un échange tient à une mauvaise communication entre les deux parties. Ne pas commencer par s’assurer qu’on parle la même langue risque de couper court à la conversation. Ne pas se mettre préalablement d’accord sur les termes d’un échange risque de provoquer bon nombre de frictions.

  Ainsi, si vous désirez saupoudrer votre quotidien d’incertitude, d’incompréhension, de médisance, voire de désespoir, établissez des échanges de données sans en définir les conditions.

  Du côté de vos sources, branchez vous donc sans prévenir. Si vous n’êtes pas identifié comme consommateur, vous ne pourrez pas être prévenu en cas de changement. Si vous ne connaissez pas la structure, le format, la définition, la fréquence de rafraîchissement, attendez-vous donc à passer par la case mauvaise qualité de donnée.

  Du côté des utilisateurs, si vous ne décrivez pas les données que vous mettez à disposition, la fréquence et l’heure de rafraîchissement, le dispositif prévu en cas d’incident

  Les embûches : les “data contracts” qui permettent de définir, entre un fournisseur de données et un consommateur, la structure attendue, les formats, les noms, la qualité de donnée et le niveau de service. Niveau de service : à quelle heure me garantit-on que la données est rafraîchie chaque jour (dans le cas d’un batch quotidien) et en combien de temps puis-je espérer un retour à la normale suite à un incident

3. Data Product

J’ai parfois, au cours de ma carrière, magnifiquement réussi des projets ratés. Techniquement viables, performances correctes, résultats conformes… et très peu utilisés. Comment en étais-je arrivé à une telle prouesse ? Le besoin m’avait semblé limpide : je devais exploiter une source de données dont j’avais analysé et compris le contenu, ce qui m’avait permis alors d’en mettre à profit tout le potentiel. Seulement voilà, le résultat était devenu trop complexe et pas assez pratique à utiliser.

Au fond, comment échouer dans son projet data : en traitant les données indépendamment du besoin, en se reposant sur sa propre interprétation.

Mais une autre approche moins évidente peut tout aussi bien vous emmener vers les abîmes de l’échec. Je l’ai également expérimenté à plusieurs reprises. Il s’agit de demander aux utilisateurs ce qu’ils veulent. Plusieurs problèmes peuvent alors se poser :

• récolter un seul point de vue non représentatif
• mixer plusieurs points de vue qui manquent de cohérence
• se baser sur des visions idéales trop décorrélées de la réalité
• s’engager sur une liste de courses, longue et sans fil conducteur

Les embûches : l’approche produit. Chez Sicara, l’association de la stratégie technique et de la stratégie produit représente un obstacle majeur au ratage. Les entretiens et les “Go and see”, permettent de comprendre le métier des utilisateurs, leur façon de travailler et les fonctionnalités clés à leur mettre à disposition. A chaque itération, l’approche “inspect and adapt”, la recherche de la valeur finale, la transparence sur la priorisation du backlog, les discussions avec le client sont les moyens mis en oeuvre pour constamment chercher à prendre la bonne direction.

Pour en apprendre plus sur le sujet, je vous oriente vers le post LinkedIn d’Antoine Grivot et vous invite à consulter notre offre Design useful data products. Ou encore son article Data as a product.

Sur l’approche produit également, l’article en 2 temps de Gaspard Sagot  sur comment créer un produit IA, partie 1 et partie 2.

Conclusion

Comme on l’a vu, l’échec d’un projet data est à la portée de tous. Mais que vous soyez en quête de succès ou d’échec, vous aurez tout intérêt à connaître toutes les raisons qui pourront faire de votre projet data un complet ratage. C’est l’une des leçons que je retiens de ma première année à Sicara : voir les problèmes en face, les écrire, les décrire, les analyser, les comprendre. Les imaginer aussi, afin de prendre conscience de tout ce qui pourrait faire rater un projet. C’est ce qui m’a permis d’apprendre et de progresser durant cette année.

Si vous voulez en savoir plus sur nos méthodes et l’expertise data chez Sicara, contactez-nous.