Thursday, August 8, 2013

Indicateurs du début de la fin en DSI

Il y a de ces signes qui ne trompent pas, le navire DSI va droit à l'iceberg. Avec le temps, on apprend à en connaître certains. On devrait pourtant les partager davantage. Ci-dessous un petit florilège.

Il y a cet outil réseau, made in DSI, que j'appelle les SOCKS-étoile-étoile. Les SOCKS ou, dans leur implémentation Microsoft, les Winsocks, ont été développés pour permettre d'offrir un traitement de type "proxy" aux protocoles qui n'ont pas été développés pour être proxyfiés. Très belle attention.
Dans la pratique, une DSI a souvent un proxy pour le web et un firewall pour le reste. Le firewall étant lourd à configurer, on n'y rajoute pas souvent des règles et la DSI "installe les SOCKS" à un utilisateur qui a des besoins réseaux inhabituels. N'ayant pas le temps de les configurer, la DSI établit une configuration de base qui autorise tous les protocoles réseau, vers toutes les destinations (ce que j'appelle étoile-étoile ou *:*), avec la promesse que ce ne sera que temporaire. Sauf que le temporaire devient permanent et que les utilisateurs SOCKS-ifiés se multiplient. A ce rythme, en un rien de temps, le proxy et le firewall sont devenus inutiles et les terminaux des vrais nids à virus.

Il y a ceux dont le nom seul évoque l'échec d'une DSI, comme Microsoft Access. Partant d'une très bonne intention, complémenter le service informatique pour les petits problèmes locaux, les utilisateurs développent des "bases" en Access.
Elles sont développées sans les compétences en développement => Elles deviennent in-maintenables, du vrai Write-Only. Elles sont développées loin des cadres de l'informatique de l'entreprise => Elles ne s'intègrent pas aux processus de la DSI, telles la sauvegarde ou la documentation. Dans le meilleur des cas, elles occasionnent des coûts imprévus gigantesques lorsqu'il faut les intégrer dans un cadre plus sérieux, c'est-à-dire les re-développer depuis zéro. Dans le pire des cas, les services en deviennent dépendants et, quand elles craquent car mal développées et non sauvegardées, elles occasionnent des arrêts de travail de ces services.
Certaines grandes entreprises ont même pris l'initiative d'interdire Access dans toute l'entreprise.

Menace plus insidieuse qu'Access, il y a les outils équivalents à Access. Un exemple : FileMaker Pro. On ne s'en méfie pas car il est cher. On se dit donc que ceux qui l'achètent en feront un usage raisonnable. Point du tout : soit il est utilisé à la DSI et il devient un outil comme un autre, soit il est utilisé par des utilisateurs finaux bien-intentionnés et c'est la rebelote d'Access. Pire encore, devrais-je dire, car les vraies compétences sur pareils logiciels sont plus rares et plus chères que celles sur Access.

Un autre outil vicieux est le tableau croisé dynamique d'Excel. Quelle belle fonctionnalité ! Cet outil permet de faire des calculs, des comptes, des sommes sur des tableaux de données. On lui donne les données, on lui dit quels champs compter, sommer, et il se débrouille... en théorie. C'est un outil magnifique pour la recherche, pour l'analyse ponctuelle de données, mais en aucun cas pour la fabrication de chiffres en production. Il est trop complexe, trop lié à sa représentation à l'écran dans Excel, difficile à manipuler. Résultat, trop souvent on obtient un résultat sans être absolument certain que ce soit le bon. « J'obtiens tel nombre d'occurrences du problème X, mais est-ce en comptant les doublons sur les deux tableaux ou sans les compter ? » Un bon outil théorique mais pas pour la prod.

Sur le plan managérial, il y a un indicateur net d'iceberg droit devant : l'externalisation d'un silo applicatif (cloud ou non). Si c'est un petit silo, ce n'est pas très grave, mais s'il est grand et qu'il est vraiment silo, c'est-à-dire que tant l'application que son infrastructure, sa maintenance et ses évolutions sont externalisés, alors il y a vraiment du souci à se faire : la DSI a un concurrent au sein de l'entreprise.

Un autre indice qui devrait mettre la puce à l'oreille quant à un possible iceberg est l'accumulation de tickets non traités concernant une application donnée. Ces tickets peuvent être minimes, bénins voire obsolètes mais ils renvoient une image négative et leurs auteurs s'impatientent, voire se désespèrent. C'est ce genre d'accumulation qui mène une direction à jeter le bébé avec l'eau du bain concernant un système qui marchait, dans l'ensemble, plutôt bien.

Et puis il y a le manque de plan de continuité. Le principal indice, c'est quand tout le monde parle du PCA mais que personne ne sait par où commencer, que chacun prend ses petites initiatives de son côté mais que personne ne sait qui en est responsable.

C'est un tout petit extrait et j'en rajouterai sans doute.