Le Piège du Prestige : Une Leçon d'Humilité Stratégique à Neuf Chiffres
Ma première confrontation avec la plateforme de données de notre entreprise est venue d'une réponse troublante à un ticket urgent. Trois jours après l'ouverture du ticket et après avoir contacté plusieurs personnes, l'équipe en Europe a finalement répondu à l'équipe informatique située à l'autre bout du monde : "C'est sur la liste des choses à corriger, et ce sera livré dans 3 à 6 mois."
La première question que nous avons posée était donc logique : "Qui priorise le backlog et comment peut-on obtenir une livraison plus rapide ?"
La réponse fut plus que surprenante : "Les développeurs s'en chargent."
Comment le backlog d'une plateforme de plusieurs millions d'euros pouvait-il être priorisé par des développeurs alors que les opérations commerciales du monde entier en dépendent ? C'était une question épineuse, mais tout à fait légitime dans le contexte d'une entreprise internationale où la livraison d'une équipe affecte les activités mondiales. Pour comprendre pourquoi les choses fonctionnaient ainsi, nous avons dû exhumer l'histoire stratégique de l'entreprise remontant à sept ans.
À ce moment-là, j'ai réalisé que j'étais face au symptôme d'un dysfonctionnement organisationnel bien plus profond, qui finirait par coûter à l'entreprise plus de 100 millions d'euros et d'innombrables opportunités manquées.
Le Prestige Avant l'Expertise : Quand les Grandes Enseignes de Conseil Éclipsent le Savoir Interne
L'aventure de la plateforme de données et d'analyse a commencé par l'embauche d'un prestigieux cabinet de conseil pour jouer le rôle d'oracle : "Dites-nous quelle voie emprunter !" D'un point de vue technologique, de nombreuses options existaient. Chaque fournisseur de cloud proposait une solution distincte, viable, testée et déployée dans d'autres entreprises internationales. Les options ne manquaient pas ; la stratégie concernait principalement la mission et la vision de ce que la plateforme devait accomplir, qui elle devait servir, et quel avenir elle créerait.
Le cabinet de conseil a passé quelques mois à enquêter, comme ils le font habituellement, et est revenu avec une présentation PowerPoint soigneusement élaborée pour le Directeur des Données et de l'Analytique. Ils recommandaient de construire la plateforme de données chez un fournisseur de cloud et la plateforme d'analyse chez un autre, arguant que chacun offrait des capacités uniques ou des avantages de coût dans des domaines spécifiques. Cette approche fournirait une évolutivité sans dépendance envers un seul fournisseur, affirmaient-ils, et puisque des entreprises de taille similaire avaient réussi avec cette architecture, ils étaient convaincus que cela fonctionnerait pour nous.
Le directeur des données et de l'analytique venait des équipes Finance et Contrôle opérationnel, l'un des parcours que tout membre des "Grandes Écoles" travaillant dans l'entreprise se voyait proposer, en vue de devenir Directeur, VP, PDG plus tard dans sa carrière. Peu après sa nomination, le département s'est rempli de sang neuf avec "nom à particule", comme on dit en français, devenant l'un des départements comptant le plus grand nombre de membres de l'aristocratie française et de diplômés des écoles d'élite. Cela promettait d'offrir un service de haute qualité à l'entreprise, grâce à l'excellence supposément apportée par la classe sociale supérieure de France.
Le Paradoxe du Leadership : Gérer ce que l'on ne Comprend Pas
Manuel, dont le CV et les références ne correspondaient ni à l'aristocratie, ni aux grandes écoles, ni à l'expérience des plateformes de données, a été nommé pour mettre en place la plateforme de données. C'était probablement un miracle de réseautage et une volonté de diversité des RH, l'une de ces anomalies bienvenues. Après quelques mois, il a embauché des ingénieurs logiciels pour mettre en œuvre les recommandations de la présentation. Une autre personne a été chargée de développer et de livrer la plateforme analytique. Deux équipes d'ingénierie travaillaient côte à côte, physiquement, sur deux clouds différents, avec deux méthodologies différentes.
L'équipe de la plateforme de données était entièrement composée de développeurs techniquement qualifiés (âge moyen 27 ans) avec une exposition minimale aux opérations commerciales fondamentales de l'entreprise ou à la structure de P&L. Sans mécanismes de gouvernance établis, ils fonctionnaient avec une autonomie quasi totale : déterminant les priorités des fonctionnalités, les choix d'architecture technique et les délais de livraison indépendamment des besoins du marché ou de l'impact sur les revenus. Les capacités étaient développées avec une mentalité centrée sur le siège et déployées d'abord localement, ne s'étendant aux marchés internationaux que sur demande spécifique, créant un décalage perpétuel entre les exigences du marché et les capacités technologiques. Malgré leurs aptitudes techniques, l'équipe manquait de perspective intersectorielle qui vient de l'implémentation de plateformes similaires dans plusieurs environnements d'entreprise, menant à l'innovation sans application contextuelle appropriée.
La Valeur de l'Expérience Appliquée : Quand le Processus Surpasse le Pedigree
L'équipe analytique, en revanche, a engagé une société de conseil externe spécialisée dans la technologie cloud qu'ils avaient choisie. Ces consultants possédaient non seulement des connaissances et des certifications dans les services cloud qu'ils construisaient, mais avaient également livré des plateformes similaires pour d'autres clients. Cette équipe bénéficiait également d'une exposition directe aux besoins commerciaux. Comme leurs rapports étaient consommés par les parties prenantes de l'entreprise, lorsque quelque chose ne fonctionnait pas, ils avaient les doigts dans ce que j'appelle "l'eau bouillante" : ils pouvaient voir, entendre et ressentir la douleur causée par une mauvaise conception, priorisation ou livraison. Ils employaient un scrum master professionnel pour l'équipe centrale, formaient des escouades à mesure que les demandes augmentaient, et priorisaient leur backlog en fonction des urgences et de l'impact sur l'entreprise.
Le leader technique de l'équipe analytique était un personnage atypique, fervent défenseur des valeurs de la gauche française, négociant des cryptomonnaies et entrepreneur en série comme activité secondaire, avec une maîtrise parfaite du branding, du marketing et de la communication. C'était amusant d'observer ce "choc des clans", voyant l'aristocratie française travailler main dans la main avec les riches garçons de la crypto de gauche, défendant la classe ouvrière. Un tableau magistral de "La Ferme des Animaux" de George Orwell, et comment les paradoxes et les dichotomies peuvent coexister côte à côte, dans une mini-société au sein de l'entreprise.
Ces cultures organisationnelles contrastées ont révélé comment l'approche du leadership et la composition de l'équipe impactent directement les résultats techniques et, en fin de compte, la valeur commerciale.
Les Coûts Cachés de la Dette Technique : Invisible Jusqu'à la Catastrophe
Au-delà de la personnalité, de l'éducation, de la classe sociale et des modèles de formation d'équipe, les approches d'ingénierie ont émergé comme un différenciateur marquant entre les équipes. Ayant été formé à la réalisation de projets d'ingénierie pour des usines de production dans diverses industries, j'ai apporté une approche méthodique à l'ingénierie avec toujours la standardisation à l'esprit. L'ingénierie informatique était un domaine où je pouvais rapidement repérer des anomalies, car de nombreux ingénieurs manquaient d'approches structurées pour la conception et la mise en œuvre.
Dans la conception d'usines de production, une mauvaise ingénierie devient visible pour les inspecteurs tôt ou tard. Parfois, les preuves d'une conception médiocre restent visibles tout au long de la vie de l'usine, comme lorsque des ingénieurs français ont conçu une installation de production pour les Pays-Bas en utilisant les mesures de taille moyenne françaises. Lors du démarrage, voir les collègues néerlandais se cogner répétitivement la tête contre les structures rendait palpables les défauts de conception et l'embarras qui en résultait.
En informatique, une mauvaise ingénierie peut rester cachée pendant des années. Elle est enfouie dans le code, et lorsque tout le monde est habitué à ce qui apparaît comme "non structuré", personne ne remarque les problèmes. Si vous ameniez des employés de fabrication ou d'ingénierie pour examiner le travail informatique, ils souligneraient immédiatement l'absence de revues de conception, de signatures d'autorité de conception, de conventions de nommage, de modèles d'ingénierie et de normes de documentation.
L'Excellence en Ingénierie : L'Avantage Compétitif de la Standardisation
L'équipe de données employait une approche d'ingénierie chaotique avec un minimum de meilleures pratiques, de normes ou de modèles documentés. Une tâche routinière comme l'ajout d'un nouvel ingénieur de données à la plateforme pouvait prendre des jours. Quelqu'un devait passer au crible des centaines de lignes de code de droits d'accès pour déterminer où ajouter le nom du nouvel ingénieur et quels droits d'accès lui accorder. De plus, tous les ingénieurs de données du monde entier devaient passer deux entretiens avec l'équipe centrale pour approbation.
L'équipe de la plateforme analytique, composée de consultants plus expérimentés, a adopté une approche entièrement différente. Après avoir livré leurs premiers projets, ils ont documenté les processus en détail, établi des conventions de nommage du déploiement de l'architecture à la prestation de services, et créé des modèles standardisés couvrant les pipelines et divers composants d'ingénierie. Ces modèles incorporaient les meilleures pratiques tout en permettant la personnalisation pour des scénarios complexes. L'équipe offrait des services de conseil technique aux ingénieurs ayant des conceptions ou des questions complexes. Ils ont également standardisé le processus de recrutement avec des questionnaires écrits contenant des questions pratiques, interviewant des candidats à l'échelle mondiale, et fournissant une perspective ouverte et orientée vers le développement pour l'intégration de toute personne possédant des certifications et des connaissances intermédiaires. Cette mentalité collaborative s'était développée au fil des années de travail dans différents contextes, entreprises et secteurs d'activité, apportant de précieuses perspectives externes.
Le Piège de la Bureaucratie : Quand la Sécurité Devient un Obstacle aux Affaires
Un autre aspect déroutant de la conception de l'équipe de données provenait de leur compréhension limitée des opérations commerciales et des systèmes. La configuration de sécurité avait peu de sens pratique. Les utilisateurs qui avaient déjà accès aux données dans les applications métier - ayant passé des processus d'approbation avec diverses parties prenantes commerciales et informatiques - devaient créer plusieurs tickets pour accéder aux mêmes données sur la plateforme. Ces tickets nécessitaient une revue par Manuel et d'autres dans l’équipe centrale et localement, avant que l'accès ne soit accordé aux données que les utilisateurs pouvaient déjà voir dans leurs applications métier.
En réalité, le contrôle d'accès dans les applications métier était personnalisé par application plutôt que défini au niveau de l'entreprise ou basé sur les rôles. La plupart des systèmes utilisaient des accès nominatifs avec approbation commerciale, approbation informatique, ou les deux. Cela signifiait que lors de l'intégration, les employés devaient découvrir progressivement quels systèmes ils devaient utiliser et demander l'accès à chacun individuellement. Au lieu d'adopter et d'étendre les droits d'accès aux applications existantes, l'équipe de données a mis en place une couche supplémentaire de contrôles d'accès qui entravait les utilisateurs. Lorsque ce problème a été soulevé lors de réunions, leur seule réponse était : "Suivre la sécurité des applications nécessite une coordination complexe, et nous avons décidé de ne pas poursuivre cette approche."
La Sagesse de l'Organisation : La Ressource Stratégique Inexploitée
"Lequel d'entre vous a approuvé l'architecture et l'orientation stratégique de la plateforme de données et de la plateforme d'analyse ?" ai-je demandé à un groupe d'architectes informatiques lors d'un déjeuner, des années après l'établissement de la plateforme.
Leur réponse collective a tout dit : "Aucun d'entre nous !"
Un architecte a expliqué que de nombreux ingénieurs informatiques, spécialistes de l'infrastructure et architectes d'entreprise du monde entier avaient averti le Directeur des Données et de l'Analytique que la conception du cabinet de conseil ne tenait pas compte de l'histoire de l'entreprise et ne convenait pas à leurs opérations. Ils avaient souligné trois points critiques : l'utilisation de plusieurs fournisseurs de cloud créerait une complexité inutile ; trouver des ressources globalement pour des compétences cloud de niche deviendrait de plus en plus difficile ; et, de manière prémonitoire, ils avaient prédit que les utilisateurs trouveraient des moyens créatifs de contourner les exigences de validation excessive, conduisant à la prolifération de l'informatique parallèle.
La réponse du directeur a révélé comment les décisions se verrouillent prématurément : "Nous avons déjà présenté le plan au conseil d'administration, et nous ne pouvons pas le changer."
Plus tard, j'ai confirmé ce schéma en engageant des consultants ayant de l'expérience dans la banque et d'autres environnements à forte intensité de données. Au cours de leurs premières semaines, ils ont invariablement observé que notre approche double-cloud était dépassée dans leurs industries, et que d'autres services cruciaux manquaient. Mais lorsque ces préoccupations ont atteint l'équipe de données centrale, la réponse de Manuel lors des sessions de questions-réponses en disait long sur la culture organisationnelle : "Procurez-vous un compte de laboratoire et testez le service que vous voulez. Nous gardons l'architecture telle quelle."
Les organisations ne manquent rarement d'expertise. Elles manquent de mécanismes permettant à cette expertise d'influencer les décisions avant que l'élan ne les rende irréversibles. Les personnes qui comprennent le mieux vos réalités opérationnelles sont souvent celles qui ont navigué dans vos systèmes pendant des décennies, et non celles qui possèdent les diplômes les plus prestigieux ou les présentations les plus brillantes.
L'Inévitable Règlement de Comptes : Quand les Corrections Stratégiques Deviennent Inévitables
La prophétie de nos experts internes a finalement été reconnue sept ans plus tard, non par illumination, mais par la douleur.
Lorsque l'augmentation des coûts d'infrastructure cloud a alarmé le conseil d'administration, davantage de projets ont eu du mal à trouver des ingénieurs qualifiés avec une expérience avérée dans des services cloud spécifiques, et les utilisateurs, frustrés par les étapes bureaucratiques imposées par siège social, ont créé leurs propres solutions de données et d'analyse. C'est alors que nous avons dû prendre la difficile décision d'écarter les plateformes existantes et de mettre en œuvre ce que les architectes internes avaient suggéré sept ans plus tôt.
Malgré l'investissement de 65 millions d'euros dans la plateforme de première génération et la livraison de nombreux projets et améliorations, le conseil d'administration a finalement approuvé 35 millions d'euros supplémentaires pour construire la plateforme de remplacement et migrer tout depuis l'ancien système. La plateforme de nouvelle génération a priorisé l'accessibilité en libre-service pour réduire les dépenses informatiques parallèles qui avaient émergé alors que les unités commerciales cherchaient des solutions de contournement au système centralisé bureaucratique.
Le véritable coût des erreurs stratégiques se mesure dans les effets composés de l'exploitation d'un modèle erroné pendant des années, puis dans la correction douloureuse nécessaire pour retrouver la bonne voie. Sept ans de friction organisationnelle avaient créé des habitudes et des contournements qui prendraient des années à défaire.
L'Impératif Organisationnel
La gouvernance technologique stratégique exige la même rigueur que celle appliquée à l'allocation de capital, à l'évaluation des fusions-acquisitions ou aux décisions d'expansion de marché. Les décisions d'architecture technologique sont fondamentalement des décisions de stratégie commerciale avec des implications à long terme pour l'agilité organisationnelle, la réactivité aux marchés et l'excellence opérationnelle.
À mesure que les entreprises rivalisent de plus en plus sur leur capacité à exploiter les actifs de données, l'architecture soutenant ces actifs ne peut être déléguée sans une responsabilité claire envers les résultats commerciaux.
La caractéristique distinctive des organisations leaders sur le marché réside dans le développement de structures de gouvernance qui permettent une détection et une correction rapides des désalignements entre les investissements technologiques et les priorités stratégiques.
Impératifs Stratégiques : Transformer les Décisions Technologiques d'Entreprise
Si vous planifiez une plateforme de données majeure aujourd'hui, résistez à l'impulsion de simplement promouvoir un brillant ingénieur interne ou de faire appel à un prestigieux cabinet de conseil pour dicter votre voie. Engagez plutôt des consultants qui ont réellement construit des plateformes similaires pour des entreprises de votre taille. La différence entre la connaissance théorique et l'expérience éprouvée devient douloureusement apparente une fois que vous êtes profondément engagé dans la mise en œuvre.
Avant d'écrire une seule ligne de code, prenez le temps de comprendre en profondeur votre réalité opérationnelle. Connectez-vous avec les lignes commerciales à travers toutes vos géographies. Recueillez les exigences des directeurs jusqu'aux spécialistes opérationnels qui manipulent les données quotidiennement. Cette approche révèle des modèles qui resteraient autrement invisibles - les mêmes points douloureux émergeant indépendamment à travers les marchés et les fonctions.
Connectez-vous avec des architectes informatiques ayant plus de 10 ans d'expérience dans votre entreprise. Ce sont les porteurs de la mémoire institutionnelle qui peuvent expliquer pourquoi certaines approches ont échoué dans le passé. Ils connaissent les modèles organisationnels qui défieraient toute nouvelle initiative, et ils comprennent les connexions cachées entre les systèmes qu'aucune documentation n'a jamais capturées. Leur connaissance n'est pas théorique, elle a été acquise au fil des années en observant le succès ou l'échec des idées dans votre contexte spécifique.
Comme je l'ai souligné dans de nombreuses éditions d'ITOLOGY, faire ses devoirs, parler avec les parties prenantes informatiques et commerciales à l'échelle mondiale, est crucial pour comprendre ce dont les gens ont vraiment besoin. Cette approche évite de construire des systèmes que vous devrez écarter et reconstruire des années plus tard, ainsi que les coûts massifs que votre entreprise supportera parce que quelqu'un sans expertise en la matière a engagé un cabinet de conseil coûteux, présenté des recommandations au conseil d'administration sans consultation adéquate des parties prenantes, et déclenché une cascade coûteuse de conséquences.
Une stratégie affecte de nombreuses personnes, et un échantillon représentatif des personnes impactées devrait participer à sa définition. La planification stratégique n'est pas un one-man-show !
L'écoute est essentielle lors de la création d'un nouveau département, service ou capacité pour une entreprise internationale. Si vous construisez quelque chose avec des fonctionnalités fantaisistes que les développeurs jugent nécessaires tout en retardant les fonctionnalités dont l'entreprise a besoin, vous dépensez de l'argent aux mauvais endroits. Souvenez-vous : si vous n'avez pas passé assez de temps à écouter avant de lancer un projet de plusieurs millions d'euros, vous suivez une recette vouée à l'échec.
Tout le monde dans votre entreprise au niveau mondial dépend-il d'une seule équipe au siège social ou en Inde pour un service qu'ils utilisent tous pour les décisions commerciales ? Si c'est le cas, vous payez le prix de la simplification excessive, perdant de l'argent en raison de la centralisation. Prendre la voie facile entraîne un coût significatif. Cela peut donner à cette équipe le sentiment d'être importante - rois du monde - tout en frustrant tout le monde, attendant que ces "rois" traitent leurs tickets, qui sont enfouis parmi des centaines d'autres, tandis que l'équipe centralisée reste trop éloignée pour remarquer "la température montante sur le thermostat."
Les plateformes d'entreprise les plus réussies ne sont pas conçues par les ingénieurs logiciels les plus brillants. Elles sont conçues par ceux qui comprennent que la technologie sert l'entreprise, et non l'inverse.
Pour plus de contenu comme celui-ci, visitez : https://www.globaldataandbi.com/resources
Avertissement : Toute ressemblance avec des personnes réelles, vivantes ou décédées, des événements réels ou des organisations existantes serait purement fortuite.
#ITOLOGY #TransformationDigitale #StratégieIT #Leadership #GouvernanceTechnologique #ArchitectureDEntreprise #AnglesMortsStratégiques #DetteTechnique #GouvernanceTI #StratégieEntreprise #DSI #Dirigeants #LeadershipDesDonnées #PerspectivesEntreprise #AvenirDeTI
Écrit par: Zahra Fathisalout
Entrepreneur | Investisseur | Stratège Tech | Connecteur de Personnes & d’Idées | Métamorphiste, Fondatrice & PDG, Global Data and BI Inc.
Je dirige Global Data and BI Inc., une entreprise spécialisée dans les solutions de données, Intelligence d’Affaires (BI), automatisation et intelligence artificielle (IA) de niveau entreprise pour les grandes corporations. Grâce à nos cadres techniques propriétaires, nous avons mené à bien plus de 70 projets data.
Notre TechParity Framework™ aide les organisations internationales à augmenter la représentation des femmes dans les métiers de la tech, des données et de l’IA, grâce à des programmes de formation ciblés.
