Bataille d’experts – le retour : Savoir trancher un sujet technique lorsqu’on est DSI

Dans un précédent article je vous donnais quelques conseils pour fournir les bons arguments à son DSI afin qu’il tranche sur des sujets techniques. J’inverse les rôles aujourd’hui, pour m’adresser à nos CIO, nos CTO, ou encore nos DSI / RSI, en somme à nos patrons de l’informatique.

Et là le conseil va être beaucoup plus simple : si vous en êtes à trancher des sujets techniques, c’est que vous avez raté le coche dans votre organisation. Vous avez un background technique ? C’est une très bonne chose. Mais si vous êtes le chef il faut bien se dire que ce n’est pas grâce à votre compétence technique, soyons honnêtes. Ne croyez donc pas que votre avis vaut mieux que celui de vos troupes, sur le terrain, qui elles développent encore plus de 6 heures par jour.

Un DSI n’est pas nommé pour répondre lui même au débat technique. Il est nommé pour constituer une équipe de confiance, capable de le faire pour lui. Le job d’un exécutif c’est plein de choses passionnantes, mais ça n’inclut pas de prendre des décisions opérationnelles.

Donc si un sujet technique est escaladé jusqu’à vous (quel ETL utiliser pour le prochain projet, quelle modélisation choisir pour son datawarehouse…), sachez reconnaître le problème organisationnel sous-jacent, et réagir en fonction.

Pour ça, voici les grandes étapes à suivre :

  • D’abord, constituez-vous un état-major d’experts en qui vous avez confiance. Qu’ils soient internes (c’est mieux) ou externes, identifiez des individus qui savent vous dire non, qui savent vous dire quand vos décisions sont mauvaises, quelle que soit leur place dans la hiérarchie. N’hésitez d’ailleurs pas à tester la capacité à la franchise de cet état-major de temps en temps : demandez des avis externes, croisez le retour de plusieurs personnes, posez des questions théoriques douloureuses dont vous savez les réponses, auditez le résultat de vos audits… Car en effet, la confiance n’exclut pas le contrôle.
  • Une fois ces référents identifiés, appuyez-vous sur eux pour vous conseiller dans la décision. Non pas pour vous expliquer le sujet technique, mais plutôt pour vous clarifier les intérêts et conflits d’intérêts de chacun, et comprendre pourquoi votre organisation n’a pas su répondre au problème. Vous n’êtes pas là pour trancher le choix de l’éditeur de l’ETL, vous êtes là pour comprendre pourquoi votre architecte décisionnel n’a pas réussi à faire appliquer ses recommandations.
  • Enfin, n’ayez pas peur de prendre et d’assumer des décisions qui ne font pas de compromis. Si un sujet escalade jusqu’à vous, il sera forcément chargé émotionnellement et votre décision fera obligatoirement des malheureux. N’essayez donc pas de satisfaire tout le monde, vous n’arriverez qu’à des demi-mesures qui feront trainer la situation dans le temps. Mieux vaut une vraie tristesse, qu’une fausse joie (dixit les experts). Soit les recommandations de votre architecte sont mauvaises, alors il vous faudra l’accompagner dans la mise à jour de sa compétence ; soit l’équipe projet est trop arrogante pour reconnaître la sagesse de l’architecte, et un effort de management doit être fait pour remettre les choses à plat.

Le résultat c’est que vous ne choisissez pas à la place de vos équipes, vous corrigez votre organisation pour qu’elle réponde elle-même à la question, et aux prochaines du même acabit.

Si sur le papier ça a l’air simple, il est clair que dans la vie de tous les jours c’est plus complexe. On a tous une tendance à vouloir jouer les superhéros, à sauter dans l’action et sauver les situations. Une caractéristique d’ailleurs encore plus présente chez les individus ayant réussi à se hisser dans les fonctions exécutives. Mais il faut savoir déléguer les décisions au bon niveau de responsabilité (le terrain), et respecter ces décisions. Pour un collaborateur, il n’y a rien de pire qu’un désaveu de la part de sa hiérarchie, surtout si de son point de vue il faisait le nécessaire pour protéger l’entreprise. Il est également important d’éviter le micro-management, car intervenir sur toutes les décisions c’est encourager vos équipes à vous masquer les problèmes afin de conserver leur autonomie.

Enfin, et je conclue peut-être avec le message le plus important de cet article : en cas de problème ne blâmez pas une personne, blâmez plutôt les processus et/ou l’organisation. Cette règle est à la base du Lean IT, dont un des piliers est le respect de la personne. Elle est essentielle au bon fonctionnement du groupe. Au-delà de la considération à avoir pour son prochain, c’est également un excellent coup de pouce à la transparence, puisque l’apparition d’un défaut dans l’organisation sera l’occasion d’améliorer les conditions de travail des équipes.

Bataille d’experts : fournir les bons arguments à son DSI pour trancher sur des sujets techniques

Avec la fonction d’architecte, et plus globalement la séniorité (autrement dit la vieillesse, oui, merci…), vient la responsabilité un peu particulière d’arbitrer les désaccords sur des sujets techniques. Si la plupart du temps l’expérience permet de trancher immédiatement une discussion, il apparaît régulièrement des débats où une théorie vaut l’autre. Soit ça, soit un des acteurs fait preuve d’un dévouement sans faille à son idée et refuse la sagesse de ses aînés. Très saine attitude soit dit en passant.

Quand il y a peu d’enjeu, ou que ces débats ont lieu assez tôt dans le projet, on réalise des prototypes, on teste, et si le perdant est un gentleman, toute l’opération prend une tournure sympathique. C’est d’ailleurs plutôt sain de laisser s’exprimer tous les avis, et de tester effectivement où se situe la vérité. Tout le monde apprend énormément, on disperse les mythes issus du culte du cargo, les tensions s’apaisent et j’irais même jusqu’à dire que le respect nait entre les participants.

A l’autre extrême se situent les batailles d’experts sur des sujets ultra pointus, avec toute la direction en arbitrage, des centaines de K€ de facturation dans la balance et des relations client/fournisseur au bord du gouffre, et là on rigole beaucoup moins.

Tableau "Les Sabines" par Jacques-Louis David - Une bataille de l'antiquité avec des gens tout nus

Depuis les consultants portent des costumes, et c’est quand même moins gênant.

J’ai vécu ce type d’escalade plusieurs fois dans ma carrière, et l’une d’elles est suffisamment éloignée dans le temps pour que je puisse en parler sans fâcher personne, surtout qu’aujourd’hui je commence à croire que j’avais tort – je vais y venir.

J’étais donc employé chez un grand nom du BTP, en interne et non comme consultant, et j’étais en charge du pôle de développement pour la plateforme décisionnelle des ressources humaines. En gros je gérais une petite équipe de développeurs en mode projet sur le domaine RH, en tant que manager et chef de projet, et dans mes objectifs j’avais également pour fonction d’assurer la qualité, la maintenabilité et l’évolutivité des applications de mon périmètre.

Une des plus grosses applications de ce dit périmètre était évidemment la plateforme de reporting aux 1’500 responsables de paye du groupe (en SSRS), appuyé sur un datawarehouse (SQL Server) d’un beau gabarit pour suivre les 70’000 collaborateurs du groupe.

L'armée de Terracotta

Heureusement, on ne modélise plus les datawarehouses en 1:1

Il est à noter que cette application m’avait précédée dans la société, elle avait été réalisée par un prestataire que je ne nommerai pas. Moi j’étais arrivé à peu près au moment du passage au lot 2 sur 8, avec un lot 1 globalement validé et déployé en production.

Vous vous doutez bien que si le DSI avait décidé d’internaliser les chefs de projet (moi côté réalisation, un très bon camarade côté étude), c’est que ça coinçait dans son rapport avec le prestataire. Les consultants ayant complétement séduit leur client – la DRH – ils se permettaient des comportements inexcusables vis-à-vis des acteurs de la DSI.

Notre rôle était donc de restaurer l’équilibre dans le projet en apportant la compétence décisionnelle côté DSI. Je n’ai jamais eu le détail du plan de bataille du DSI, mais rétrospectivement je pense que l’objectif était de prouver que la solution n’était pas très propre techniquement, pour décrédibiliser le prestataire auprès de la MOA (la DRH) et le remplacer. Aujourd’hui j’ai appris ma leçon : vouloir régler des problèmes politiques avec des arguments techniques, ça ne marche pas. A l’époque j’étais encore utopiste, donc je me suis lancé.

Un soldat qui utilise une guitare à la place d'un fusil

Bien choisir ses armes, c’est important.

Et sur le plan technique, il y avait beaucoup à dire sur cette solution. Modélisation dimensionnelle déplorable (200+ dimensions, en flocon et en étoile en même temps, SCD implémentés dans la table de fait…), ETL en procédures stockées (100+), plus de 150 tables d’agrégats, bugs de sécurité critiques sur SSRS, etc. etc. J’ai monté un dossier de 50 pages sur le sujet et évidemment on a convoqué le directeur technique du prestataire, responsable de l’architecture, pour discuter de tout ça.

Ce qu’il en ressort, c’est qu’avec beaucoup d’assurance, voire d’arrogance, on fait avaler n’importe quelle couleuvre technique à un décideur. Et c’était à prévoir : un DSI comprend des questions de performance, de fonctionnalités, de livraison et de MOA satisfaite. L’élégance du code, la beauté d’une normalisation, le respect des bonnes pratiques, ce n’est pas vraiment son problème tant qu’ils ne s’illustrent pas par des jours-hommes, à travers une facturation qui explose ou des retards incontrôlés. Donc oui, il était d’accord avec nous sur le principe, mais nos arguments techniques ne lui ont jamais permis de gagner l’avis du DRH face à la solution effectivement déployée, effectivement accessible aux utilisateurs et à peu près performante.

Et c’est là que tient la réponse à la question posée par cet article : comment fournir des bons arguments à son DSI pour l’aider à trancher un sujet technique ?

  1. Illustrez vos arguments techniques par des impacts projets forts. Donnez des chiffres (performances, coût de maintenance à N+1, coût des régressions, coût du support, surcharges sur les développements, effondrement du ROI…), rappelez les risques sur l’évolutivité, la difficulté à trouver un prestataire de remplacement qui s’engagera à cause de la spécificité des développements… Et illustrez tout ça, faites des prototypes, calculez les performances, faites des plannings qui prouvent ce que vous avancez. Apportez des éléments concrets qui ont du poids dans le référentiel de valeur de votre décideur.
  2. Et attendez votre heure. Cela ne sert à rien d’avoir raison trop tôt. Choisissez vos batailles, ne partez pas en croisade contre la terre entière, soyez patient. Il vous faudra attendre qu’on vienne vous chercher, qu’on ait besoin de vous, pour avoir un impact quelconque sur la situation. Par contre soyez prêt quand le moment viendra (confère point 1). Attention, je ne dis pas de rester en sous-marin et de ne pas lever d’alertes, au contraire : donnez votre avis franc, honnête et informez votre hiérarchie de ce que vous percevez. Mais sachez accepter votre destin, jusqu’au moment où l’opportunité de faire changer les choses apparaîtra. On ne sait jamais la carrière de qui, là-haut dans la direction, dépend de la réussite ou de l’échec du projet…

Et si vous n’arrivez vraiment plus à supporter votre quotidien, comprenez que c’est vous qui n’êtes pas à la bonne place, et pas l’inverse.

Pour conclure, pourquoi ai-je dit qu’aujourd’hui je pensais avoir eu tort à l’époque? Parce qu’au final : ok le prestataire était 2 fois plus cher que les prix du marché (vraiment fois 2), ok la modélisation était inacceptable, ok la qualité de données n’aurait jamais réussi à dépasser 90% de précision et ok les coûts de maintenance étaient partis pour exploser, mais le reporting sortait et la MOA était satisfaite du deal. Tout est là : je suis parti en croisade avec des arguments purement techniques (point 1) alors qu’à cet instant t, le système donnait satisfaction à ses utilisateurs (point 2), et trop contents d’avoir enfin un vrai reporting automatisé, ils n’étaient absolument pas concernés par le moyen terme. C’était donc perdu d’avance.

Aujourd’hui ce que je me dis c’est qu’il y a suffisamment de gens qui ont besoin d’aide et qui le demandent, pour ne pas vouloir aller aider ceux qui estiment ne pas en avoir besoin. Tout du moins pour un consultant décisionnel hein, si vous êtes médecin ou pompier ce n’est pas la même histoire…

MàJ 16/10/2012 : Si vous avez lu jusqu’à la fin, vous serez surement intéressé de savoir que j’ai écrit depuis l’article symétrique: Savoir trancher un sujet technique lorsqu’on est DSI.

PS : Salut aux camarades tombés pour la cause, ils se reconnaitront 😉

Dilbert du 23/06/2012

Une situation malheureusement bien plus courante que ce qu’on pourrait croire. D’ailleurs si vous vous êtes déjà décidé avant-même d’avoir les chiffres, pas la peine de les demander en urgence.

Dilbert du 23/06/2012

Traduction approximative:

Dilbert: Je viens de terminer l’analyse frauduleuse justifiant la décision que vous aviez déjà prise.

Dilbert: C’est une trahison totale des actionnaires et d’un mépris rare à tous ceux qui croient au comportement rationnel dans l’entreprise

Boss: Merci. C’est exactement ce que je voulais.

Dilbert: Je vous en prie.