Vous avez certainement suivi, comme tout le monde, les péripéties de la non-construction de l’aéroport de Notre-Dame des Landes. Je pensais, également comme tout le monde, que cette affaire était définitivement enterrée. Elle l’est, bien sûr ! Mais j’étais loin d’imaginer qu’elle aurait des répercussions dans ma DSI.
Tout a commencé quand j’ai émis l’idée qu’il nous fallait un nouveau système d’information. L’actuel était arrivé à la limite de ses capacités. Nous n’avions plus de slots pour parquer nos projets, des livrables se perdaient régulièrement, malgré notre réelle expertise pour gérer les bagages intellectuels de nos équipes de développeurs. Et trop d’utilisateurs se pressaient à nos comptoirs pour déposer des cahiers des charges de plus en plus lourds ! Nos pistes d’audit devenaient également très encombrées. Sans parler des grèves à répétition de nos pilotes de processus et de nos Data stewards. Les multiples atterrissages en catastrophe de projets et non moins multiples décollages budgétaires (c’est fou la vitesse à laquelle un budget peut décoller…) produisaient des nuisances pour les utilisateurs riverains.
J’avais trouvé le terrain pour notre nouveau système d’information : un nouveau périmètre métier tout neuf, en jachère depuis longtemps, encore peuplé d’espèces en voie de disparition : le papier et le crayon. Tout allait pour le mieux lorsque j’ai déployé plusieurs CRS, autrement dit des Campagnes de Réécriture de Software. Mais je me suis d’emblée heurté à de fortes résistances. Bref à la création d’une ZAD (Zone d’Applications à Défendre). Au début, je ne me suis pas méfié, espérant que cette poignée d’irréductibles se rende et admette que l’intérêt général était de construire ce nouveau système d’information.
Le problème est qu’il remettait en cause le statut et le nombre de nos développeurs. J’avais évidemment privilégié les progiciels, alors que notre système d’information historique avait été construit progressivement, grâce à de nombreux développements spécifiques et les équipes qui vont avec, devenues, il faut bien le reconnaître, un peu pléthoriques… Et qui sont aujourd’hui retranchées dans leur ZAD. Comme je les ai un peu laissées faire, elles en ont profité pour développer un élevage de patches. Il faut dire que mes développeurs sont plutôt écolos, préférant cultiver eux-mêmes leurs lignes de codes (rassurez-vous, ils ne les sniffent pas encore…). Ils rechignent à travailler avec des produits industriels, en l’occurrence des progiciels commercialisés par des multinationales pour la plupart américaines, bourrés d’additifs propriétaires qui ont tendance à détraquer un système d’information, voire à le tuer si on en consomme trop…
Lorsque j’ai commencé à vouloir déployer davantage de Campagnes de Réécritures de Software, ils se sont rebiffés. J’ai eu droit à des cocktails Molotov… La recette ? Une taupe chez mes zadistes me l’a confiée : un tiers d’Open Source, un tiers de code propriétaire, des morceaux de Cobol et des API contaminées. A coup sûr, un tel mélange explose dès qu’un DSI s’en approche… Aucun ne résiste à l’effet de souffle qui peut le propulser hors de son job en moins de temps qu’il n’en faut à un Chief Digital Officer pour prononcer le mot « transformation » dans un dîner en ville.
En retour, j’ai bombardé mes zadistes d’avenants provenant d’un stock de cahiers des charges qui étaient encore dans les cartons et n’avaient pas été dégoupillés. Mais tout cela a été vain, j’ai été contraint d’abandonner mon projet d’extension de notre système d’information. Car les politiques s’en sont mêlés. Le PDG ne souhaitait surtout pas faire de vagues (sa reconduction par les actionnaires l’obsède…). Tout le Comex lui a emboité le pas pour suggérer que, « finalement, ce n’est pas une si bonne idée de se mettre les utilisateurs à dos. » Il a donc lancé un référendum, qui a donné 50-50 entre les pour et les contre… D’où l’abandon du projet… « Vous comprenez, je ne tiens pas à avoir la population d’utilisateurs contre moi », m’a expliqué notre PDG.
Evidemment, cette affaire nous a coûté en indemnités : il fallait bien payer les cabinets de conseil qui étaient intervenus pour commencer le travail et avaient pris soin d’insérer dans leurs contrats des clauses ad hoc « au cas où… » La solution retenue, la plus « politique » et la moins pragmatique selon moi, a consisté à étendre l’infrastructure existante, de manière à l’adapter aux « gros porteurs » de données : d’où un ajout de serveurs, une extension de notre infrastructure pour absorber des utilisateurs supplémentaires et la construction d’un nouveau bâtiment pour abriter les demandes d’enregistrements de projets… Maigre consolation : nous avons bien évidemment réussi à évacuer la Zone Applicative à Défendre et à nettoyer les déchets laissés par les « pizza teams »… On a juste laissé pousser quelques lignes de codes, histoire de conserver un peu de naturel. Quant à nos zadistes, la plupart sont partis développer leurs compétences dans un Larzac (Lieu Accueillant pour Recréer de la Zizanie Avec Certitude)…