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.

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.

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é.

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 😉