Tribunes

Edito : Le DSI, le client anarchiste

Bertrand Lemaire, rédacteur en chef de CIO

Le client est roi. Il a droit de commander et d'être servi. Mais le DSI, lui, a beau être le client de nombreux fournisseurs, il semble avoir aboli la monarchie de son plein gré.

PublicitéComment en est-on arrivé là ? C'est une question que, souvent, je me pose. Franchement, sincèrement, chers lecteurs DSI, connaissez-vous un seul domaine industriel où les dysfonctionnements nécessitant des correctifs incessants sont jugés normaux ? Connaissez-vous un seul secteur industriel où les fournisseurs font payer la garantie, et de plus en plus cher de préférence ? Connaissez-vous une seule activité économique où le client est pieds et poings liés avec ses fournisseurs, ne pouvant en changer qu'avec de multiples coûts et difficultés, quand c'est techniquement possible ? Connaissez-vous un seul domaine de propriété intellectuelle où le créateur de valeur doit se soumettre aux desiderata des fabricants de ses outils, comme si le fabriquant de peinture était propriétaire des toiles des plus grands peintres ?
Oui, vous en connaissez un. Un seul. Le vôtre, l'informatique.

La standardisation, clé de la concurrence et de la liberté

Je me rappelle, il y a quelques années, combien le simple fait d'affirmer que la standardisation ISO des formats bureautiques était nécessaire m'a valu comme remarques désobligeantes. En bon crypto-communiste, je voulais donc tuer l'innovation ! Non, je voulais juste défendre le droit des utilisateurs à changer de fournisseur comme bon leur semble. Et les débats houleux reviennent dans l'actualité avec la nouvelle version -plus impérative- du RGI (Référentiel Général d'Interopérabilité).
Or l'usage de formats propriétaires en informatique est similaire au fait de rendre un fabricant de peinture propriétaire d'une toile d'un grand peintre. Quand on créé un document (texte, image ou autre), c'est une propriété intellectuelle, une valeur économique, qui appartient à son créateur. L'éditeur du logiciel n'a aucun droit dessus. Aucun. En théorie.
Car si le format utilisé ne permet pas de reprendre sa création avec un autre outil que celui d'origine, dans les faits, l'éditeur de l'outil d'origine est propriétaire de la création en question. Au point que si la politique de l'éditeur fait disparaître le produit, l'oeuvre disparaît en même temps puisqu'elle ne sera rapidement plus accessible.

Etre un client rigoureux

La première règle, lorsque l'on achète un produit, quelque qu'il soit, est : comment je fais pour, demain, m'en passer ou en changer ? Si je me décide pour une Peugeot 308, mon garage acceptera demain que j'y range une Renault Mégane. Ces deux véhicules utilisent le même carburant et se pilotent de la même façon sur les mêmes routes. Et si un informaticien vient dire à Renault et Peugeot qu'ils n'innovent pas ou que leurs produits sont simples, il sera probablement bien accueilli. En informatique, c'est tout de suite plus compliqué de vouloir faire la même chose.
Il y a quelques années, l'informatisation de la médecine a fait pousser les éditeurs pour médecins libéraux comme des champignons. La plupart de ces éditeurs ont disparu. Et les médecins ont souvent perdu de nombreuses données, rien n'étant prévu pour les récupérer. Sommes-nous vraiment à l'abri de la répétition d'un tel désastre ? Les clauses de back-up sur les hébergements externalisés en tous genres sont bien sympathiques mais si l'hébergeur disparaît du jour au lendemain sans laisser d'adresse (sauf celle du Tribunal de Commerce ayant déclaré sa faillite) ou si les données récupérées sont dans un format inexploitable, le DSI sera bien avancé...

PublicitéLe scandale de la maintenance

Il est vrai que, de toutes les façons, si vous voulez que votre logiciel fonctionne, il vous faudra payer sa maintenance. Et, normalement, si le produit disparaît, la prestation de migration sera présentée. Normalement. Si l'on peut ne pas trop avoir de doutes sur les grands progiciels du marché, il en est tout à fait autrement sur les multiples logiciels métier comme l'exemple des logiciels médicaux nous l'a montré.
Mais qu'est-ce donc que cette maintenance ? Il s'agit de permettre le maintien en conditions opérationnelles. Autrement dit : réparer les dysfonctionnements (maintenance corrective) et mener des améliorations mineures pour, par exemple, suivre une évolution réglementaire (maintenance évolutive). Les principes légaux évoluant peu, l'évolution pour cause réglementaire est rare et souvent tout à fait mineure (Par exemple : l'état à imprimer pour faire sa déclaration de TVA n'a plus tout à fait la même esthétique). Quant aux évolutions fonctionnelles, il devrait appartenir au client de choisir de les acheter ou non. Pourquoi la maintenance est-elle, en pratique, obligatoire ?
Parce que l'éditeur fait payer ses bugs. Voilà pourquoi. C'est bien la maintenance corrective qui est payée. C'est la seule que les DSI achètent vraiment dans la majorité des cas, prenant la maintenance évolutive comme un bonus alors qu'ils préféreraient acheter ponctuellement un petit patch qui les arrange, n'achetant pas ceux qui ne les intéressent pas.
Pourquoi acceptent-ils de payer ce qu'il faut bien appeler une garantie légale obligatoire contre les vices cachés ? Parce que rien n'est simple en informatique. Si le logiciel plante parce qu'on a installé une nouvelle imprimante ou que l'on tente de le faire communiquer avec un autre logiciel, le temps de trouver qui est coupable et de lui faire un procès, l'entreprise cliente aurait fait faillite. Pourtant, quand une Peugeot 308 ou une Renault Mégane tombe en panne, c'est beaucoup plus simple. Si la panne vient du fait que l'essence n'était pas de bonne qualité, le responsable est vite trouvé. Normal : toutes les interfaces, tous les échanges sont normalisés. La formule de l'essence est connue (du moins, sa base réellement nécessaire). La taille des routes est connue. On peut changer les pneus comme on le veut.
Encore une fois, le fournisseur informatique a réussi à faire admettre aux DSI que ses turpitudes sont normales. Et cela parce que la normalisation n'est pas la règle mais l'exception. Si les entrées/sorties de chaque type de logiciel étaient documentées et normalisées, changer de PGI serait un jeu d'enfant. Et cela n'empêcherait nullement l'innovation. La standardisation de l'essence et des routes n'a jamais empêché Renault et Peugeot de faire évoluer leurs voitures.

Des choix à faire ou des non-choix à assumer

Bien sûr, la fameuse base installée, le Legacy, empêche les DSI d'adopter du jour au lendemain toutes les bonnes pratiques. Mais de là à renoncer totalement à être un client-roi, il y a une marge.
Certains choix d'architecture devraient être écartés d'office, ce qui n'est pas le cas. Par exemple, le simple fait qu'un fournisseur veuille imposer une maintenance sur une simple base de données devrait faire écarter ce fournisseur. Choisir de légèrement accroître la performance en économisant deux sous de mémoire ou de processeurs en stockant des procédures dans une base de données dans un format propriétaire irrécupérable, c'est une faute. Et ce simplement parce que le système d'information sera alors l'otage de l'éditeur de la base de données.
Au moment de créer ou de renouveler un module du système d'information, c'est de la responsabilité du DSI de faire des choix d'architecture appropriés. Or, dans les critères permettant de définir « approprié », il y a certes des considérations de performance technique propre à un instant t dans un contexte donné, mais il doit aussi y avoir des considérations sur le long terme.
Et ces considérations doivent inclure le fait de pouvoir changer de fournisseur si celui-ci devient un révolutionnaire refusant la royauté de son client. Les DSI sont souvent les seuls rois qui abolissent de leur propre chef la monarchie. De vrais anarchistes, quoi.