Que faire maintenant ? Anticiper les changements de conception

Il m'arrive très souvent de discuter avec des personnes au sujet de la conception, des plans et de l'architecture de leurs systèmes. Et bien souvent, cette discussion intervient trop tard et les conceptions sont soit déjà mises en œuvre, soit partiellement mises en œuvre. Cela peut s'avérer très frustrant lorsque la conception en cours a été jugée non idéale pour la situation.

Je comprends le sentiment de frustration qui découle d'une telle situation, mais c'est une chose à laquelle nous, dans l'informatique, devons faire face de façon très régulière, et gérer cette réaction de manière constructive est une compétence informatique essentielle. Nous devons devenir maîtres de cette situation, tant sur le plan technique que sur le plan émotionnel. Nous ne devons pas nous laisser paralyser par elle ; il s'agit d'une situation naturelle que tout professionnel de l'informatique rencontrera régulièrement. Elle ne devrait pas être décourageante ni paralysante, mais il est tout à fait compréhensible qu'elle puisse être ressentie ainsi.

L'une des principales raisons pour lesquelles nous y sommes si souvent confrontés est que l'informatique est un domaine immense, comportant un très grand nombre de variables à prendre en compte dans chaque situation. C'est aussi un domaine éminemment créatif, où il peut exister de nombreuses approches viables pour un problème donné. Qu'il existe ne serait-ce qu'une seule « meilleure » option est rarement vrai. Il y a normalement de nombreuses options concurrentes. Parfois elles sont très proches les unes des autres, parfois ces options sont radicalement différentes, ce qui rend leur comparaison réellement très difficile.

Une autre raison majeure est que les facteurs évoluent. Il peut s'agir de nouvelles techniques ou de nouvelles informations qui apparaissent, de nouveaux produits qui sont lancés, de produits qui sont mis à jour, de prix qui changent ou de besoins métier qui évoluent à l'approche, voire au cours même, des processus de décision et de conception. Ce rythme de changement n'est pas quelque chose que nous, en tant que professionnels de l'informatique, pouvons espérer maîtriser un jour. C'est une chose que nous devons accepter et gérer du mieux que nous le pouvons.

Un autre point que je vois souvent négligé est qu'une solution qui était idéale au moment de sa conception peut ne plus l'être si la même décision était prise aujourd'hui. Cela ne constitue en aucune manière une déficience de la conception d'origine, et pourtant j'ai vu beaucoup de gens y réagir comme si c'était le cas. Le scénario le plus courant dans lequel je vois les gens adopter ce comportement est l'aversion pour l'utilisation du RAID 5 dans la conception du stockage moderne, le RAID 6 et le RAID 10 étant les alternatives populaires pour de bonnes raisons. Mais cette aversion pour le RAID 5, répandue depuis environ 2009, n'a pas toujours existé, et du milieu des années 1990 jusqu'à la toute fin des années 2000, le RAID 5 n'était pas seulement viable : il était très souvent la meilleure solution au regard des besoins métier et techniques en présence (l'accroissement de l'aversion à son égard a été pour l'essentiel graduel, et non soudain). Cependant, beaucoup de gens considèrent le RAID 5 comme un choix médiocre aujourd'hui, ce qui se comprend, mais appliquent cette nouvelle aversion à des systèmes conçus et mis en œuvre il y a longtemps, parfois il y a près de vingt ans. Cela n'a aucun sens et relève purement d'une réaction émotionnelle. Que le RAID 5 ait été le meilleur choix pour un scénario en 2002 n'implique nullement qu'il sera encore le meilleur choix en 2015. Mais de même, que le RAID 5 soit un mauvais choix en 2015 pour un scénario ne diminue ni ne nie en rien le fait qu'il était très souvent un excellent choix il y a plusieurs années.

On m'a demandé de nombreuses fois ce qu'il fallait faire une fois que des décisions de conception moins qu'idéales avaient été prises. « Que faire maintenant ? »

Apprendre quoi faire lorsque la perfection n'est plus envisageable (comme si elle l'avait jamais réellement été, toute l'informatique étant affaire de compromis) est une compétence très importante. Les premières choses que nous devons aborder sont les problèmes émotionnels, car ils sapent tout le reste. Nous devons faire de notre mieux pour prendre du recul, accepter la situation et agir de façon rationnelle. La dernière chose que nous voulons faire, c'est prendre une situation non idéale et l'aggraver en tentant de justifier rétroactivement de mauvaises décisions ou en cédant à la panique.

Accepter qu'aucune conception n'est parfaite, qu'il n'y a aucun moyen de toujours faire les choses parfaitement bien et que composer avec cela fait simplement partie du métier de l'informatique, voilà la première étape. Prenez du recul, respirez profondément. Ce n'est pas si grave. Ce n'est pas une situation unique. Tout professionnel de l'informatique qui fait de la conception traverse cela en permanence. Vous devez vous efforcer de prendre les meilleures décisions possibles, mais vous devez aussi accepter que cela puisse rarement être fait — personne n'a accès à suffisamment de ressources pour réellement y parvenir. Nous travaillons avec ce que nous avons. Donc nous voici. Et maintenant ?

L'étape suivante consiste à évaluer la situation. Où en sommes-nous maintenant ? Dans bien des cas, la mise en œuvre est terminée et il n'y a plus rien à faire. La situation n'est pas idéale, mais est-elle mauvaise ? Très souvent, la plus grosse erreur que je vois chez les personnes confrontées à une conception déjà mise en œuvre est qu'elle est trop coûteuse — généralement, les solutions « meilleures » ne le sont pas parce qu'elles sont plus rapides ou plus fiables, mais parce qu'elles sont moins chères, plus simples ou plus rapides à mettre en œuvre. C'est une situation malheureuse, mais difficilement paralysante. Quel que soit le temps ou l'argent dépensé, ce montant a dû être jugé acceptable à l'époque et a dû être approuvé. Le mieux que nous puissions faire, dès maintenant, c'est tirer des enseignements du processus de décision et tenter d'éviter les dépenses excessives à l'avenir. Cela ne signifie pas que la solution existante ne fonctionnera pas, ni même qu'elle ne fonctionnera pas remarquablement bien. C'est simplement qu'elle n'a peut-être pas constitué un choix parfait au regard des besoins métier, principalement financiers, en jeu.

Il existe des situations où une conception mise en œuvre ne répond pas correctement aux exigences métier énoncées. Cela est heureusement moins fréquent, d'après mon expérience, car c'est une situation bien plus difficile. Dans ce cas, nous devons apporter certaines modifications afin de satisfaire nos besoins métier. Cela peut se révéler coûteux ou complexe. Mais les choses ne sont peut-être pas aussi graves qu'elles le paraissent. Souvent, les réactions à cette situation sont trompeuses et la situation peut bien souvent être rattrapée.

La première étape, une fois que nous nous trouvons dans une situation où nous avons mis en œuvre une solution qui ne répond pas aux besoins métier, consiste à réévaluer les besoins métier. Cela ne veut pas dire que nous devrions arranger les besoins pour les façonner de manière à ce qu'ils correspondent à ce que notre système est capable de satisfaire, pas du tout. Mais c'est un bon moment pour revenir en arrière et voir si les besoins initialement énoncés sont réellement valides ou s'ils n'ont simplement pas été suffisamment examinés ou, plus probablement encore, pour aller voir si les besoins métier ont changé pendant la période où la mise en œuvre a eu lieu. Il se peut que la solution mise en œuvre réponde en fait aux besoins métier réels, même s'ils ont été mal énoncés à l'origine ou parce que les besoins ont évolué au fil du temps. Ou il se peut que les besoins métier aient changé si radicalement que même une planification parfaite serait à l'origine restée en deçà des besoins actuels, et que le fait que la solution mise en œuvre ne soit pas aussi performante qu'attendu soit de moindre conséquence. J'ai été très surpris de constater à quelle fréquence cette vérification des besoins métier a transformé une solution jugée inadéquate en une solution « surdimensionnée » qui, en réalité, a coûté plus cher que nécessaire, simplement parce que personne n'avait remis en question des besoins métier surévalués ou n'avait interrogé la valeur financière de certains investissements technologiques.

La deuxième étape consiste à établir un nouveau point de référence technologique. C'est une étape très importante pour aider l'informatique à ne pas tomber dans le piège du sophisme des coûts irrécupérables. Il est extrêmement courant, pour quiconque — cela n'est en rien propre à l'informatique —, de considérer le temps et l'argent dépensés sur un projet et de supposer que poursuivre dans la voie initiale, aussi insensée soit-elle, est la marche à suivre, parce que tant de ressources ont déjà été consacrées à cette voie. Mais cela n'a évidemment aucun sens : la manière dont vous êtes parvenu à votre état actuel est sans importance. Ce qui importe, c'est d'évaluer les besoins actuels du service et de l'entreprise et de faire l'inventaire des solutions, technologies et ressources actuellement disponibles. Compte tenu de l'état actuel, la meilleure voie à suivre peut être déterminée. Toute considération accordée aux efforts consentis pour parvenir à l'état actuel ne fait qu'induire en erreur.

Un bon exemple du sophisme des coûts irrécupérables se trouve dans le jeu d'échecs. À chaque coup, il est important de réévaluer l'ensemble des coups, des risques et des stratégies disponibles, car les coups qui ont permis d'atteindre l'état actuel n'ont aucune incidence sur les coups qui ont du sens pour la suite. Si l'on faisait intervenir le meilleur joueur d'échecs du monde ou un formidable algorithme d'échecs en cours de partie, ils n'auraient besoin d'aucune connaissance sur la façon dont l'état actuel s'était constitué — ils se contenteraient d'évaluer l'état actuel et de bâtir une stratégie en conséquence.

C'est exactement ainsi que nous devrions nous comporter en informatique. Notre état actuel est notre état actuel. Pour la planification stratégique, peu importe ce qui s'est déroulé pour nous y amener. Nous ne nous soucions de ces décisions et de ces coûts que lorsque nous menons un processus de rétrospective afin de déterminer où la prise de décision a pu échouer, dans le but d'en tirer des leçons. Apprendre à nous connaître nous-mêmes ainsi que nos processus est très important. Mais c'est là une tâche très différente de la planification stratégique de l'initiative en cours.

Ce qu'il y a de regrettable ici, c'est que nous devons recommencer nos processus de planification, mais cette fois avec, supposons-le, davantage de matière sur laquelle travailler. Mais cela ne peut être évité. Dans les pires cas, les budgets ne sont plus disponibles et il n'y a aucune ressource pour corriger la conception défaillante et atteindre les objectifs métier nécessaires. Des compromis sont parfois nécessaires. Se contenter de ce que l'on a est parfois le mieux que nous puissions faire. Mais, dans la grande majorité des cas semble-t-il, une combinaison de budget supplémentaire ou de réutilisation créative des produits existants peut suffire à remédier à la situation.

Une fois que nous sommes parvenus à un état où nous avons remédié à nos insuffisances, que ce soit simplement en acceptant que nous avons trop dépensé, sous-livré, ou que nous nous sommes ajustés pour répondre aux besoins, nous avons l'occasion de revenir en arrière et d'examiner nos processus de prise de décision. C'est en faisant cela que nous espérons grandir en tant qu'individus et, dans la mesure du possible, à l'échelle de l'organisation, apprendre de nos erreurs, ou déterminer s'il y a même eu des erreurs. Chaque entreprise et chaque individu commet des erreurs. Ce qui nous distingue, c'est la capacité d'en tirer des leçons et d'éviter ces mêmes erreurs à l'avenir. La croissance découle principalement du fait d'éprouver de la douleur de cette manière, et même s'il est souvent désagréable d'y faire face, c'est ici que nous avons la meilleure occasion de créer une valeur réelle et durable. Ne reportez pas et ne sautez pas cette occasion de révision, qu'il s'agisse d'un examen rigoureux et personnel que vous menez vous-même, d'un examen formel et organisationnel conduit par des personnes formées à cet effet, ou de quelque chose entre les deux. Plus tôt les processus de décision sont évalués, plus le souvenir sera frais et plus tôt la correction de cap pourra prendre effet.

La dernière étape que nous pouvons accomplir consiste à entamer, dès que possible, le processus de décision visant à concevoir un remplacement de la mise en œuvre actuelle, une fois la révision du processus de décision achevée. Cela ne signifie pas nécessairement que nous devrions avoir l'intention de dépenser de l'argent ou de modifier nos conceptions dans un avenir proche. Pas du tout. Mais en étant extrêmement proactifs dans la prise de décision de conception, nous pouvons tenter d'éviter les problèmes du passé en nous accordant davantage de temps pour la planification, plus de temps pour le recueil des exigences et la documentation, une meilleure visibilité sur l'évolution des exigences dans le temps en revisitant régulièrement ces exigences afin de voir si elles demeurent stables ou si elles changent, davantage d'occasions d'obtenir l'adhésion et l'investissement de la direction et des pairs dans la décision, et une meilleure compréhension du domaine du problème, de sorte que nous soyons mieux armés pour modifier la conception envisagée ou pour savoir quand l'abandonner et tout reprendre de zéro avant de la mettre en œuvre la prochaine fois. Cela pourrait aussi, potentiellement, nous donner une meilleure chance de codifier un savoir organisationnel qui pourrait être transmis à un successeur, au cas où vous-même ne seriez pas en position de décision ou de mise en œuvre lorsque le prochain cycle se présentera.

Avec de bons processus rationnels et une bonne compréhension des étapes à suivre dans le cas d'une conception ou d'une mise en œuvre de systèmes moins qu'idéale, nous pouvons nous remettre de nos faux pas et, dans la plupart des cas, non seulement nous en remettre à court terme, mais aussi prémunir l'organisation contre les mêmes erreurs à l'avenir.