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

Cet article s'adresse à celles et ceux qui commandent une stratégie, qui l'approuvent, ou qui devront ensuite la mettre en œuvre : secrétaires de commune et skarbnik (trésoriers) dans les administrations, présidents et membres des conseils d'administration des entreprises communales, présidents et directeurs financiers d'entreprises, ainsi que responsables informatiques qui souhaitent que ce document les aide enfin dans leurs discussions budgétaires. J'ai traité séparément les erreurs typiques des stratégies des administrations dans l'article Stratégie IT dans les JST (collectivités territoriales polonaises) : les erreurs les plus fréquentes. Ici, je me concentre sur ce que doit contenir le document lui-même.

Pourquoi les stratégies finissent dans un tiroir

D'après ce que j'ai pu observer dans des organisations publiques et privées, une stratégie est rarement mauvaise sur le fond. Elle finit dans un tiroir parce qu'elle devient inutilisable dès la première décision concrète.

• Elle part d'une vision, pas d'un inventaire. Personne n'a vérifié quels systèmes, contrats et dépendances existent déjà, de sorte que le plan s'écarte de la réalité dès le premier achat.
• Elle décrit des objectifs, mais pas d'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 chacun de leur côté.
• 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 propriétaire. Le document a été adopté par une résolution ou une décision du conseil d'administration, et sa vie s'est arrêtée là.
• Elle est rédigée dans le jargon informatique. Le conseil d'administration et le conseil n'y trouvent pas de réponses à leurs questions : combien, pourquoi, que se passera-t-il si l'on ne fait rien.

Sept éléments d'une stratégie qui sert réellement

1. L'état des lieux. Un registre des systèmes avec propriétaire, 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 de la manière dont s'articulent les registres, les processus, les intégrations et les 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 naître, et quels systèmes doivent hériter de ces données.
3. Les standards. Quelques règles applicables à chaque achat : comment nous attribuons les droits d'accès, à quoi doit ressembler l'interface pour les collaborateurs, comment nous documentons les exigences, quels droits sur les données nous devons détenir, quel langage (standard) nous utilisons pour décrire les processus, comment nous sécurisons la sortie d'une collaboration.
4. La feuille de route, avec une distinction entre obligation et investissement. D'un côté, ce que nous devons faire parce que la loi ou un contrat l'exige (dans les administrations, par exemple un système de type EZD — système de gestion électronique des documents et des dossiers —, le KSeF — système national polonais de facturation électronique —, ou e-Doręczenia — le service polonais de distribution électronique) ; de l'autre, ce que nous faisons parce que cela en vaut la peine. Avec un ordre et une justification. Par exemple : une facture récupérée depuis le KSeF peut être enregistrée dans le dossier de l'affaire, mais selon la loi, elle doit d'abord 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. Le budget, avec une distinction entre investissement et maintien en condition opérationnelle. Le coût de maintien augmente à chaque nouveau système et doit être visible avant même que la décision d'achat soit prise. J'en parle plus en détail dans l'article sur le coût total de possession (TCO). Gardez à l'esprit que le déploiement est en général un investissement ponctuel (CAPEX), mais que, du point de vue du budget, la continuité d'activité et la sécurité reposent notamment sur la maintenance et les mises à jour (OPEX), qui se répètent année après 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 donne un avis sur l'offre, quelles clauses doivent figurer dans le contrat. J'en ai décrit une partie dans l'article sur le cahier des charges (SWZ) sans vendor lock-in.
7. Le propriétaire et le rythme de révision. Une personne précise, côté direction, doit 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 révisions.

Exemple pratique

La société Wodociągi Miejskie (compagnie des eaux municipale), appartenant à une commune de taille moyenne, préparait son plan d'achats informatiques pour l'année suivante. Dans un premier temps, le service informatique a demandé le remplacement simultané des ordinateurs de bureau, l'achat d'un nouveau système de supervision et la modernisation de l'infrastructure réseau. Le conseil d'administration a cependant demandé de démontrer quelles dépenses étaient les plus urgentes du point de vue de la continuité de l'approvisionnement en eau.

L'entreprise a commencé par un inventaire : elle a recensé les équipements, les logiciels, les connexions réseau et les contrats de maintenance, puis les a rattachés à des processus concrets — du service client jusqu'au pilotage des stations de traitement. Il est apparu qu'une partie des équipements assurant la communication avec les stations arrivait en fin de support, et que la documentation des connexions 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 premier lieu, il a été prévu de mettre en ordre et de sécuriser les connexions avec les installations techniques, ainsi que de remplacer les équipements dont la panne pourrait compromettre la supervision de l'approvisionnement en eau. Ensuite, un renforcement des sauvegardes et de la supervision a été planifié. Le remplacement d'une partie des ordinateurs de bureau a été reporté à une étape ultérieure.

Devant le conseil d'administration, le service informatique ne justifiait plus le budget par l'affirmation générale que « le matériel est vieux ». Il a montré une chaîne de dépendance : composant d'infrastructure précis → processus soutenu → conséquence d'une panne → achat proposé. Grâce à cela, le conseil a 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, plus visible pour les collaborateurs.

Quand un conseiller indépendant est-il nécessaire ?

Il est possible de rédiger une stratégie en interne si l'organisation dispose de quelqu'un ayant le temps nécessaire et une vue d'ensemble. Un appui extérieur est utile lorsque l'état des lieux n'est pas documenté, lorsque la stratégie doit servir de base pour défendre le budget devant le conseil, le propriétaire ou la maison mère, lorsque plusieurs obligations réglementaires arrivent en même temps, ou lorsque la direction et le service informatique n'ont pas la même lecture des priorités et qu'il faut quelqu'un pour traduire une perspective dans l'autre.

Je prépare des stratégies de numérisation et des architectures cibles à partir d'un inventaire : avec feuille de route, standards, règles d'achat et un budget défendable.