Stratégie

Neuf mensonges avec lesquels les DSI s'abusent eux-mêmes

CIO Etats-Unis a identifié neuf proclamations habituelles de DSI qui sont bien souvent de purs mensonges dans lesquels ils s’empêtrent.

Retrouvez cet article dans le CIO FOCUS n°143 !

Quand les Etats-Unis inspirent l'Europe

Pour un retour en douceur de vos vacances, CIO vous propose de voyager aux Etats-Unis. Nos confrères de CIO Etats-Unis travaillent sur des expériences de DSI d'Outre-Atlantique qui peuvent inspirer les DSI européens. Nous avons ici traduit quatre de leurs dossiers sur des sujets techniques,...

Découvrir

Si Achille était un CIO, le mensonge à lui-même serait son talon. Il serait certain que l'alignement stratégique de l'entreprise et de son informatique serait rigoureux, que la sécurité informatique seraient à l'épreuve des balles et que tous les projets arriveraient en temps et heure. Les CIO préparent une catastrophe en se mentant à eux-mêmes comme l'a montré CIO Etats-Unis.

Publicité« O quelle toile enchevêtrée que nous tissons lorsque nous pratiquons d'abord pour tromper », a expliqué le romancier écossais Walter Scott. Mais peu importe la façon dont la toile est enchevêtrée quand quelqu'un d'autre est la cible. Cela n'a rien à voir avec le désordre produit lorsque nous nous trompons nous-mêmes.
Et nous nous trompons nous-mêmes, non pas parce que nous voulons délibérément définir les mauvaises priorités, prendre de mauvaises décisions et poursuivre les mauvais objectifs, mais parce que émettre des voeux pieux est beaucoup plus facile que de regarder le monde à travers des lunettes transparentes.
Voici neuf situations courantes où les DSI mentent, pas à leurs équipes ou à leurs collègues d'autres directions, mais à eux-mêmes.

Mensonge du DSI n°1 : nous sommes alignés avec la stratégie de l'entreprise.

« Aligner l'informatique avec la stratégie de l'entreprise » ressemble tellement à un grand dessein nécessaire à accomplir que de nombreux DSI instituent des processus élaborés de gouvernance informatique pour s'assurer que cela devienne une réalité. C'est dommage que peu d'entreprises de toutes tailles soient alignées avec leurs propres stratégies. L'alignement avec la stratégie de l'entreprise consiste généralement, dans les faits, à apaiser politiquement les responsables de la société ou à instaurer un système de rétroaction.
C'est l'informatique de bricoleur : nous vous donnerons tout ce que vous demandez, aussi longtemps que vous financerez le projet. Avec la rétroaction, l'informatique peut ne pas être alignée avec la stratégie de l'entreprise, mais elle correspond au budget de celle-ci. Si cela s'harmonise avec l'entreprise, tout va bien, et si ce n'est pas le cas, eh bien, c'est le problème de quelqu'un d'autre.

Mensonge du DSI n°2 : La seule raison de mettre à niveau un logiciel est lorsqu'une nouvelle version fournit une valeur métier importante.

Non seulement cela semble convaincant mais cela fait joli au cours d'un comité directeur. Un CIO qui fait une telle déclaration est clairement axé sur la stratégie de l'entreprise (et s'aligne sur elle) et ne peut être accusé de dépenser pour la technologie en elle-même. Encore mieux, le budget informatique peut diminuer car il n'a plus à intégrer le coût de la mise à jour des logiciels.
Les CIO qui font ce choix, cependant, n'ont jamais survécu à une mise à jour ayant entraîné des pertes de données ou de fonctionnalités à cause d'un saut de plusieurs générations technologiques. Ou alors, s'ils ont réussi, ils ont surtout réussi à accuser quelqu'un d'autre.
Les mises à niveau logicielles font partie de la maintenance préventive. Vous payez maintenant ou vous payez plus tard. Plus tard, c'est simplement beaucoup plus cher.

PublicitéMensonge du DSI n°3: Le grand projet critique a été retardé ? Nous allons nous rattraper sur la phase suivante et tout finir à temps.

Voici le déroulement habituel des opérations. Les délais sont justes. Donc, quiconque a créé cette catastrophe fait ce que les gestionnaires font depuis bien avant l'invention des feuilles de calcul : ils manipulent les faits jusqu'à ce que le ROI dépasse le taux de risque, se convainquant eux-mêmes que leurs hypothèses révisées sont encore, sinon entièrement, raisonnables, au moins faisables avec un peu de chance et un fort vent arrière.
L'estimation issue de la phase des exigences et des spécifications est pleine de bugs. Plus le projet est important, plus il y a d'inconnues. Chacune d'entre elles complique encore les choses. La phase des exigences et des spécifications s'allonge toujours, mais, en général, ça va. Tout le monde sait que plus on passe de temps en conception, moins on en passe dans la création du code et son test.
L'informatique étant alignée avec la stratégie de l'entreprise, la planification fonctionne en rétroplanning, en commençant par la date de livraison et en travaillant vers l'arrière sans se préoccuper du point d'arrivée. Cette fois, c'est le chef de projet qui, en désespoir de cause, manipule les faits jusqu'à ce que le calendrier semble plausible afin que personne ne l'observe de trop près. Et personne ne le fera parce que ce planning correspond à ce que chacun veut entendre.
L'état du projet finit en orange, c'est à dire en retard, sans chemin possible vers le salut, mais suffisamment de temps avant le délai que le déni remplace encore la réalité. Les gestionnaires de projets adroits prennent deux mesures lorsqu'un projet atteint cette étape. D'abord, ils pressent les tests. Cela met à la fois le projet et le teint de l'équipe dans le vert. Deuxièmement, ils commencent une recherche d'emploi avant que l'état du projet n'impacte leur réputation.
Test de niveau 1: consiste à retrouver un état d'exaltation en partant de suffisamment bas. Avec des normes suffisamment lisses et suffisamment de poids politique, même le pire code peut être transformé en production.
Test de niveau 2 : également appelé PROD. Vous testez toujours, et testez bien. La seule question est de savoir si des tests approfondis ont eu lieu avant ou après la mise en production du logiciel.
Pour finir, le nouveau CIO arrêtera l'épave du projet. Son prédécesseur fait porter le chapeau au chef de projet. Le chef de projet participe aux réunions de conduite de projet de la façon dont ceux qui ont des problèmes d'alcool vont aux Alcooliques Anonymes.

Mensonge du DSI n°4 : nous faisons de l'ITIL.

Cela pourrait ressembler à un tripatouillage sémantique, mais « faire » ITIL n'a aucun sens. ITIL est un cadre, comme ses adeptes l'expliquent avec patience à qui que ce soit prêt à écouter (généralement un public petit et apathique, ce qui n'inclut pas notre CIO auto-trompeur).
ITIL énumère les choses sur lesquelles la DSI doit être bonne. Il ne prescrit pas de méthodes pour savoir comment s'y prendre pour être bon, ce qui est tout aussi bien, car il n'y a aucun moyen de définir une méthode universelle pour réussir à tous les coups un élément de la liste d'ITIL. Vous ne me croyez pas ? Pensez à la façon dont vous réaliseriez la chose si vous travailliez dans une petite agence de publicité. Maintenant, pensez à la façon dont vous la réaliseriez au sein d'une grande entreprise ou d'une grande administration.
De plus, il y a beaucoup de CIO qui estiment « faire ITIL » avec un service d'assistance utilisateurs décemment efficace (ou, au moins, ils ont renommé leur service d'assistance pour qu'il soit devenu un « service desk »). Ils ont peut-être institué un conseil pour accompagner la gestion du changement. Celui-ci a pour mission de s'asseoir entre les développeurs de l'application et la production informatique afin qu'ils regardent tous les deux l'intermédiaire au lieu de l'autre.

Mensonge du DSI n°5 : nous sommes agiles.

Il y a des DSI qui ont adopté des techniques de développements d'applications à une ou plusieurs variantes agiles, ou sont en train de le faire, au lieu du classique cycle en V.
Parmi tous ceux qui ont réellement adopté une Méthode Agile, il y a probablement un certain nombre qui suivent une certaine agilité formelle, suivant scrupuleusement tous les formalismes de Scrum, tout en ignorant complètement l'esprit de la transformation agile.
Comme c'est le cas avec tant d'autres pratiques métiers et informatiques, il y a une différence entre la vérification des étapes formelles et l'exécution correcte du travail, les cases à cocher ne sont là que pour suivre l'évolution des réalisations.
Et on peut supposer que la moitié des DSI qui ont évité le piège de l'agilité sont partis dans l'autre sens et ils ne pratiquent pas du tout l'agilité. Ils ont institué une méthode aléatoire à la place, souvent à la demande d'un intégriste des cycles en V qui était certain dès le départ que tout effort pour être agile était voué à l'échec. Et celui-ci a fait de son mieux pour s'assurer que sa prophétie était auto-réalisatrice.

Mensonge du DSI n°6 : Nous avons adopté DevOps.

Non, vous ne l'avez pas fait. Vous n'êtes même pas agile. Vous ne savez pas lire ? Vous devez savoir, malgré tous les buzz au sujet de DevOps, que ses promoteurs n'ont pas inventé la collaboration. L'agilité -la vraie- a entraîné la collaboration entre développeurs et production bien avant la naissance de DevOps. Bien que, pour être juste, la production n'était pas le service avec lequelle les développeurs ont généralement collaboré.
Voici ce que DevOps ajoute à l'agilité. Tout d'abord, les équipes de développement incluent la production pour des raisons purement égoïstes : elles ne veulent pas attendre que leurs environnements soient construits, et ils ne veulent pas attendre un comité d'arbitrage pour déployer des modifications des logiciels. Deuxièmement, l'automatisation est partout, ce qui est une bonne idée. Devoir réaliser manuellement les migrations de logiciels est tout simplement idiot. Troisièmement, avec DevOps mais pas avec la plupart des méthodes agiles, et encore moins avec le cycle en V, le logiciel est toujours dans un état tel qu'il puisse être déployé. Et ne confondons pas : pas déplorable, déployable. Parmi les faits qui perturbent beaucoup d'équipes informatiques, il y a les limites de compatibilité entre Devops et Scrum. Kanban fonctionne de ce fait mieux.
Désolé d'être le porteur de tristes nouvelles.

Mensonge du DSI n°7 : Nous avons une culture de service.

Écoutez ces blagues en provenance du centre de support. C'est votre personnel d'assistance qui diffuse des histoires stupides d'utilisateurs. Ce n'est pas une culture de service à la clientèle. Une telle culture commencerait par le respect du client.
Peu importe, car si ce service a une culture de service à la clientèle, leur DSI penserait que le reste de l'entreprise est son client. Très mauvaise idée. Cela conduit à des concepts judicieux comme les rétroactions, c'est à dire une excellente occasion de perdre du temps, de l'énergie et de la confiance en négociant le planning des projets de l'IT.
Si ce n'est pas tout à fait clair pour vous pourquoi la notion de « culture du service à la clientèle » est une mauvaise idée, regardez ce qui se passe lorsque vous supprimez le mot « client ». Les DSI devraient favoriser une culture du service en informatique.
Comment déterminer s'ils ont ou pas une telle culture ? S'ils entendent encore des histoires stupides d'utilisateurs, ils n'en ont pas.

Mensonge du DSI n°8 : notre sécurité informatique est fine.

Trop souvent, quand il y a une liste de contrôle, la vérification des cases à cocher devient la seule préoccupation au lieu d'utiliser la liste de contrôle comme simple moyen de suivi. La sécurité informatique est soumise au même défi, en particulier lorsqu'il faut obtenir une attestation de conformité à une norme.
PCI, la norme de sécurité de l'industrie des cartes de paiement, vient à l'esprit. Vous pourriez vous rappeler que Target a perdu 40 millions d'enregistrements en lien avec ses clients en 2013 malgré sa conformité PCI. C'est la seule perte de données provenant de sociétés qui ont passé une certaine forme d'évaluation de la sécurité de l'information.
Si un CIO pense que sa sécurité informatique est fine, il a probablement tort. Ce sont les directeurs informatiques qui s'inquiètent de savoir si leur sécurité informatique n'aurait pas quelques trous qui pourraient être sur la bonne voie.

Mensonge du DSI n°9. Nos processus de gouvernance informatique nous permettent d'entreprendre uniquement des projets à forte valeur ajoutée.

Revenons à l'ensemble du point concernant l'alignement stratégique. La gouvernance de l'IT est censée s'assurer que seuls les projets ayant la plus haute valeur ajoutée sont financés. Et pourtant, peu importe la façon dont le processus est bien conçu, il est encore mis en oeuvre par la même série de personnes incapable de s'aligner les uns avec les autres. Donc, en plus d'estimer la valeur de chaque projet à l'entreprise, il y a des petites négociations et de la méchanceté dans le processus de décision définitive.
Ajoutez à cela un autre détail ennuyeux : les projets dont le bénéfice attendu est la réduction des coûts auront la priorité sur les projets dont le bénéfice attendu est l'augmentation du chiffre d'affaires. Pourquoi ? Réduire les coûts est sous le contrôle de l'entreprise. Si tout se passe selon les prévisions, les coûts diminueront effectivement. Mais faire croître le chiffre d'affaires exige que les clients fassent ce que vous voulez qu'ils fassent. Souvent, ils ne le font pas. Vous ne pouvez pas les surveiller. Vous devez les persuader.

Que retenir de tout cela? Une seule chose. Si vous êtes certain de chaque affirmation, vous êtes presque certainement dans l'erreur. Si vous êtes un DSI et que vous avez une certitude sur l'un de ces neuf sujets, ou même d'autres d'ailleurs, posez-vous cette simple question : qu'est-ce qui justifie cette certitude ?

Article de Bob Lewis / CIO Etats-Unis (Traduction et adaptation par Bertrand Lemaire)