Dette ou pas dette, telle est l’équation…

Éternel sujet d’actualité, la question de la dette technique nous est évidemment souvent soumise par nos clients. Et comme vous le savez, nous avons toujours réponse à toutes vos questions…

Premier point d’une réponse complète et détaillée, la gouvernance du risque est, de mon point de vue, intimement liée à la gestion de la dette technique. C’est en tous les cas une chose dont il faut parler, et qui, par expérience, n’est abordée que trop rarement.
En commençant par une analyse de risques, qui devrait exister dans toute entreprise soucieuse d’anticiper un peu l’avenir, la question pourra être justifiée ou justifiable pour arbitrer les éléments qui seront sujets à une dette technique choisie. Je ne parle pas là d’une analyse de risques IT, mais bien de celle globale à l’entreprise, présentant les enjeux, criticités, impacts, points sensibles, etc., dans leur ensemble.
Elle n’est donc pas du ressort de la DSI. C’est depuis cette analyse de risques globale que l’on pourra faire, au niveau DSI cette fois, une analyse de risques IT et en particulier apprécier de façon pragmatique les conséquences d’une défaillance : conséquences effectives, chiffrées, concrètes, compréhensibles par une DG. Et donc choisir.
Simple, évident, mais vous connaissez forcément des confrères (rappel : un confrère est quelqu’un qui fait la même chose que vous, mais moins bien) qui font des choix, des arbitrages, sans avoir les moyens de les étayer par des impacts business.

Autre version concrète d’une dette technique fréquemment rencontrée chez nos clients : une politique de mise à jour défaillante voire – c’est en fait souvent le cas – absente au niveau des logiciels et systèmes.
Globalement, il n’y a pas de raison de ne pas faire les mises à jour proposées, suggérées et recommandées par les éditeurs et constructeurs, si ce n’est peut-être encore un peu de précaution quant aux effets de bord possibles. Pourtant, entre le risque d’une vulnérabilité zero-day et le plantage dû à une mise à jour qui ne se passe pas très bien, tout est question de gestion du risque.
Mais quitte à choisir entre les deux, il me semble plus raisonnable de faire les mises à jour trop tôt plutôt que trop tard.
Soyons directs et égoïstes : les conséquences d’une mise à jour seront par ailleurs toujours à mettre au débit de l’éditeur/constructeur, tandis que celles d’un déficit de mise à jour ne seront imputables qu’à votre propre politique.
De façon plus pragmatique et modérée, une période raisonnable et limitée, mais surtout définie, procédurée et respectée en environnement de recette sera une solution idéale pour pratiquer quelques tests de non-régression, notamment.

Plus globalement, mettre à jour, mettre à niveau, monter les versions, remplacer par les nouvelles technologies (toujours plus efficaces, plus efficientes, plus rapides, plus économiques, plus écologiques…) semble une bonne idée.
Bien évidemment et comme toujours, attention aux excès. J’ai en tête un client en particulier, à la tête d’un cabinet de première importance mondiale, qui avait pour politique clairement donnée à son DSI de « prendre ce qu’il y a de mieux ». Cette consigne était évidemment adaptée avec mesure dans son application, et c’est bien grâce à son DSI, brillant, sage, et qui n’abusait pas de cette liberté, que cette ligne directrice IT était pérenne.

Et c’est peut-être là que les DSI doivent encore trouver des marges de progression : c’est une question de posture.
Si l’on n’a pas la chance de tomber sur une DG ou un Comex qui vous fait confiance « aveuglément » – ne rêvons pas, bien sûr -, il semble nécessaire de montrer que l’on sait gérer avec efficacité, sagesse et conscience la dette technologique, le budget IT et les enjeux associés.
Et justement, pour ce faire, il faut avoir d’une part la compétence et sans doute l’expérience, et d’autre part le savoir, au sens philosophique du terme, de ce qui est « bon » pour notre entreprise. Cela n’est possible qu’en étant au plus près des décisions, et même en amont des discussions, y compris stratégiques : pas simplement pour avoir au plus tôt les informations et « tout » savoir, mais pour pouvoir percevoir les chemins, les leviers, les éléments qui ont permis à la direction de l’entreprise de faire ces choix-là.

C’est cela, me semble-t-il, l’alignement stratégique que nous inscrivons tous dans nos SDSI -et qu’il m’arrive encore de faire inscrire par mes clients DSI. J’ai donc du mal – et de l’admiration pour ceux qui y parviennent autrement – à comprendre comment on peut être un bon DSI sans être directement dans un organe de gouvernance de l’entreprise. C’est, me semble-t-il, le seul moyen de pouvoir gérer, parce qu’anticipée, prévue, maîtrisée, et surtout adaptée au contexte, cette fameuse dette technique, avec une efficacité pérenne.
______________________________________

Par Gabriel Chataînois, Dirigeant d’une petite société de conseil
Gabriel Chataînois est le pseudonyme du dirigeant d’une société de conseil bien réelle

Abonnez-vous à la newsletter hebdo d'IT for Business !

Rejoignez notre liste de diffusion pour recevoir toutes les semaines une sélection d'articles et quelques autres surprises préparées spécialement pour vous par notre rédaction.

ABONNEZ-VOUS !

Nous vous envoyons un e-mail de validation !