Pourquoi je n’ai jamais vu une DSI fonctionner correctement : le cas Amazon Web Service (AWS) et d’autres cas
18 ans dans les services informatiques en partant du jeu vidéo, en passant par le e-commerce, petites ou grandes entreprises, et en 18 ans je n’ai jamais vu une seule DSI prendre une décision qui n’allait pas transformer le budget IT en tonneau des danaides.
Le cas Amazon Web Service ou l’étoile de la mort.
Un petit exemple ? pour une petite/moyenne PME/PMI, choisir Amazon contre n’importe quel autre cloud qui se respecte, c’est juste 50% de couts en plus, juste après avoir signé et en mode récurrent voir exponentiel car l’écosystéme amazon est juste fait pour bouffer votre budget, pas pour vous rendre service.
C’est son business model. Ecoutez le CTO d’Amazon WS en conférence et il vous explique le comment du pourquoi.
Pourquoi les DSI de petites et moyennes entreprises courrent vers Amazon ?
Vous connaissez le marketing ?…
Amazon a une belle marque au niveau IT et vous payez Amazon comme vous pouvez votre Apple, et pour les mêmes raisons.
Pour faire parti du club…sentiment d’appartenance, etc.. bref
le DSI dans ce cadre-là a un double effet “Kiss cool” :
- il se couvre car avec Amazon, il n’y a rien besoin d’expliquer. Le CEO au dessus de lu commande ses couches pour enfants chez Amazon, donc tout va bien.
- il prend sa carte du club comme son copain de la boite d’en face…ils pourront faire du golf en parlant d’Amazon
Amazon c’est à peu près toujours une bétise de le prendre sauf si vous vous appelez Coca-Cola ou Amazon (sic).
Pour le reste, il n’y pas le début d’un raison technique pour courir vers Amazon…
…en terme stratégique c’est juste une erreur gravissisme si vous êtes une grande société “non-américaine” car vous donnez vos datas, vos process à un futur concurrent qui vous écrasera le moment venu.
Le “Je sais faire mon métier el le vôtre aussi(amen)”
La DSI (“traditionnelle”, on y reviendra) sait tout faire.
Un développeur qui prend du grade et qui devient incapable de coder une ligne de code, c’est comme un enseignant qui devient un inspecteur de l’éducation nationale, cela ne sert plus à rien, pire c’est dangereux.
C’est le problème du code : on ne vieillit pas bien dedans.
La capacité typiquement à estimer correctement une charge de travail IT est directement dépendante du temps passer à coder.
Vous loupez 3 ans d’évolutions des frameworks, vous ne pouvez plus travailler ou presque dans un environnement professionnel.
C’est Terminé. Game Over. La benne vous attend…ou la promotion.
Inutile de dire que votre capacité à signer le “BON” bon de commande est quelque peu dégradée.
La tentation est forte alors de remettre en cause le bien fondé de la demande pour échapper aux conséquences de votre absolue incapacité à choisir la bonne solution technique : c’est le “Je sais faire votre boulot” c’est à dire que je suis plus qu’un tekos, je suis aussi comptable, marketeur, biologiste ou joueur de tennis….
Là alerte, cela veut juste dire que votre DSI en face ne comprends plus rien à la technique.
C’est un mécanisme de défense rhétorique classique mais une mauvaise nouvelle pour vos finances.
Que reste-t-il alors ?
Là vous avez 2 catégories de DSI : l’ancien sachant qui se croit toujours sachant et le manager qui devient un “servant leader” en reconnaissant ses lacunes techniques.
L’ancien sachant qui se croit toujours sachant a le mérite de rassurer car pour lui, vous le connaissez ou l’avez connu, tout ira toujours bien. C’est nettement mieux que le DSI avec des lacunes qui prend du temps pour répondre et ne renvoie pas toujours une image d’une sérénité absolue.
Pour la DSI sachante, c’est un vrai plan soviétique : les remontées vers le board seront toujours extraordinaires pendant que les équipes se perdent dans des choix technologiques délirants et incompréhensibles.
Au final, un champs de mines où le métier veut tuer l’IT et vice-versa…et des choix de bousins technologiques : au choix : SAP, Magento, Amazon, EzPublish (si ça existe encore) où une ligne de code coûte 10, 20, 30 fois plus cher qu’une techno correctement choisie.
Je ne parle pas des délirum JAVA que les ingénieurs adorent et qui transforment des rêves éveillés en cauchemard du quotidien. JAVA c’est bien pour l’interopérabilité et pour faire fonctionner le même code partout (oui très bien), par contre faire un truc spécifique qui ne sera jamis porté ailleurs en JAVA cela se discute quand même un minimum.
Après un bon développeur reste un bon développeur quelque soit le language. C’est vrai aussi. Amen
Faut-t-il tuer les DSI ?
La réponse est clairement oui.
Dans des structures modernes – on le voit chez les GAFAS – , la notion même de DSI centralisée et centralisante n’existe plus.
Les “Self-Steering Teams” capables de fonctionner de manière autonome sur des projets isolés ou interconnectés sont des modèles qui fonctionnent bien.
Les projets open-source ont largement démontré que les structures horizontales où ceux qui dirigent au niveau IT sont encore de vrais codeurs ont largement plus de succès que les silos technocratiques où vous avez 5 chefs incapables de comprendre la moindre ligne de code pour 1 développeur actif.
Pour cela il faut accepter la perte de contrôle de la part de la direction comme un prérequis qui laisse une autonomie large aux équipes en contact direct avec les besoins métiers.
Il doit bien sûr exister des fonctions transversales capables de donner un sens, fixer une stratégie technologique et s’assurer que tout reste plus ou moins cohérent mais ces fonctions doivent être des fonctions support et non décisionnelles.
De plus, plus vous aurez d’équipes prenant des chemins différents, plus vos chances de découvrir la nouvelle pépite du moment augmenteront…et le partage de connaissance bien planifié sera un retour sur investissement inestimable à terme.
