Une stratégie IT qui ne finira pas dans un tiroir : que doit-elle vraiment contenir ?

Ce billet s'adresse à celles et ceux qui commandent une stratégie, la valident ou devront ensuite l'exécuter : sekretarz (secrétaires de commune ou de powiat) et skarbnik (trésoriers) dans les administrations, présidents et membres de conseils d'administration de spółki komunalne (sociétés communales), présidents et directeurs financiers d'entreprises, ainsi que responsables IT qui souhaitent que le document les aide enfin dans les discussions budgétaires. J'ai traité séparément des erreurs classiques dans les stratégies des JST (collectivités locales) dans le billet Stratégie IT dans les JST : les erreurs les plus fréquentes. Ici, je me concentre sur le contenu du document lui-même.

Pourquoi les stratégies finissent dans un tiroir

D'après ce que j'ai observé dans des organisations publiques et privées, une stratégie est rarement mauvaise sur le fond. Elle finit dans un tiroir parce qu'elle ne peut pas être mobilisée à la première décision concrète.

• Elle commence par une vision, pas par un inventaire. Personne n'a vérifié quels systèmes, contrats et dépendances existent déjà, si bien que le plan se déconnecte de la réalité dès le premier achat.
• Elle décrit des objectifs, mais pas un ordre de priorité. Tout est important, donc rien n'est prioritaire.
• Il n'y a pas d'argent. L'absence de lien avec le budget fait que la stratégie et le plan financier vivent séparément.
• Elle ne change pas la façon d'acheter. Les systèmes continuent d'être achetés comme avant, sur la base des offres des fournisseurs, et non de standards propres à l'organisation.
• Elle n'a pas de responsable. Le document a été adopté par délibération ou par décision du conseil, et sa vie s'est arrêtée là.
• Elle est écrite dans le langage de l'IT. Le conseil d'administration et l'assemblée délibérante n'y trouvent pas de réponse à leurs questions : combien, pourquoi, que se passe-t-il si l'on ne fait rien.

Sept éléments d'une stratégie qui sert vraiment

1. L'état actuel. Un registre des systèmes avec responsable, contrat, licence, coût et fin de support, une cartographie des processus et des intégrations, un registre des risques. Sans cela, chaque point suivant relève de la conjecture. C'est le rôle de l'inventaire.
2. L'architecture cible. Une représentation simple des relations entre registres, processus, intégrations et accès. Il ne s'agit pas de schémas techniques, mais de répondre à la question : quels systèmes sont centraux, lesquels les soutiennent, où les données doivent-elles être créées et quels systèmes doivent en hériter.
3. Les standards. Quelques règles applicables à chaque achat : comment sont attribués les droits d'accès, à quoi doit ressembler l'interface pour les agents, comment documenter les exigences, quels droits sur les données nous devons détenir, quel langage (standard) nous utilisons pour décrire les processus, comment sécuriser la sortie d'une collaboration.
4. Une feuille de route distinguant obligation et investissement. D'un côté ce que nous devons faire parce que la loi ou un contrat l'impose (dans les administrations, par exemple un système de classe EZD — gestion électronique des documents et des dossiers —, KSeF — système national de facturation électronique —, e-Doręczenia — service polonais de remise électronique), de l'autre ce que nous faisons parce que c'est rentable. Avec un ordre et une justification. Par exemple : une facture récupérée depuis KSeF peut être enregistrée dans le dossier de l'affaire, mais conformément à la loi elle doit obtenir une validation sur le fond, une vérification formelle et comptable, puis achever son parcours par un enregistrement automatique dans le système financier et comptable.
5. Un budget distinguant investissement et maintien en conditions opérationnelles. Le maintien croît avec chaque nouveau système et doit être visible avant que la décision d'achat ne soit prise. J'en dis davantage dans le billet sur le coût total de possession. Retenez que le déploiement constitue en général un investissement ponctuel (CAPEX), mais que du point de vue budgétaire, la continuité d'activité et la sécurité, ce sont notamment la maintenance et les mises à jour (OPEX), qui se répètent d'année en année.
6. Les règles d'achat pour les systèmes. Quand un inventaire ou une analyse préalable à l'achat est nécessaire, qui évalue l'offre, quelles clauses doivent figurer dans le contrat. J'en ai décrit certaines dans le billet sur le SWZ (cahier des charges de l'appel d'offres) sans dépendance vis-à-vis d'un fournisseur (vendor lock-in).
7. Un responsable et un rythme de revue. Une personne précise, côté direction, devrait revoir la stratégie et les coûts de possession, au moins une fois par an à l'occasion du budget, en respectant une règle claire de périodicité de ces revues.

Un exemple concret

La société Wodociągi Miejskie, filiale d'une commune de taille moyenne, préparait son plan d'achats IT pour l'année suivante. Au départ, le service informatique demandait le remplacement simultané des ordinateurs de bureau, l'acquisition d'un nouveau système de supervision et la modernisation de l'infrastructure réseau. Le conseil d'administration a toutefois demandé de démontrer quelles dépenses étaient les plus urgentes du point de vue de la continuité de l'approvisionnement en eau.

La société a commencé par un inventaire : elle a recensé les équipements, les logiciels, les liaisons réseau et les contrats de maintenance, puis les a rattachés à des processus concrets — de la relation client au pilotage des stations de traitement. Il est apparu qu'une partie des équipements assurant la communication avec les stations approchait de la fin de son support, et que la documentation des liaisons ne couvrait pas tous les sites. Dans le même temps, la plupart des ordinateurs de bureau pouvaient continuer à fonctionner sans impact significatif sur les services essentiels.

Sur cette base, l'ordre des achats a été revu. En priorité, il a été prévu de sécuriser et de fiabiliser les liaisons avec les installations techniques ainsi que de remplacer les équipements dont la panne pourrait compromettre le pilotage de l'approvisionnement en eau. Ensuite, il a été prévu de renforcer les sauvegardes et la supervision. Le remplacement d'une partie des ordinateurs de bureau a été reporté à une phase ultérieure.

Devant le conseil d'administration, le service informatique n'a plus justifié le budget par une affirmation générale du type « le matériel est vieux ». Il a présenté une chaîne de dépendance : composant d'infrastructure précis → processus concerné → conséquence d'une panne → achat proposé. Le conseil a ainsi pu approuver les dépenses par étapes et expliquer au conseil de surveillance pourquoi la priorité avait été donnée à l'infrastructure liée à la continuité des services, plutôt qu'au matériel de bureau le plus visible aux yeux des agents.

Quand un conseil indépendant est-il nécessaire

Il est possible de rédiger une stratégie en interne, si quelqu'un dans l'organisation dispose du temps nécessaire et a une vision d'ensemble. Un appui externe est utile lorsque l'état actuel n'est pas documenté, lorsque la stratégie doit servir de base pour défendre le budget devant l'assemblée délibérante, le propriétaire ou la maison mère, lorsque plusieurs obligations réglementaires arrivent en même temps, ou lorsque la direction et l'IT n'ont pas la même vision des priorités et qu'il faut quelqu'un pour traduire un point de vue en l'autre.

Je prépare la stratégie de transformation numérique et l'architecture cible à partir d'un inventaire : avec une feuille de route, des standards, des règles d'achat et un budget défendable.