Points clés de l'article
D'abord l'inventaire, ensuite les achats
La liste des systèmes, contrats et intégrations montre ce que la préfecture possède déjà et où se situe le risque.
Un seul plan des obligations
EZD, KSC, KSeF, e-Doręczenia et le Registre central des contrats concernent les mêmes personnes et le même circuit documentaire.
Un budget dans le langage du Conseil de district
L'obligation d'un côté, l'investissement de l'autre, le coût de l'inaction exposé clairement.
Un pilote de la numérisation
Le secrétaire épaulé d'un consultant, aux côtés des informaticiens, sans créer de poste de directeur informatique.
Zdjęcia ilustracyjne
Cet article s'adresse aux secrétaires de district et aux starostas (chefs de district), ainsi qu'aux skarbniks (trésoriers) avec lesquels le budget est négocié. La préfecture de district a ses particularités : de nombreux services disposant de leurs propres systèmes métier et registres nationaux, des établissements organisationnels du district, et un statut d'entité essentielle au sens de la loi KSC (loi polonaise sur le système national de cybersécurité). L'ordre dans le système d'information n'y est donc pas qu'une question de confort, mais aussi d'obligations légales.
Pourquoi c'est plus difficile en préfecture de district
La préfecture de district traite des dossiers qui reposent sur des systèmes et registres tenus par divers prestataires et institutions : immatriculation des véhicules, cadastre géodésique, permis de construire, finances, ressources humaines et secrétariat général. Chaque service connaît son propre système, mais rarement quelqu'un a une vue d'ensemble : quels systèmes échangent des données entre eux, qui est propriétaire de quel contrat, quand se termine le support du fournisseur, et ce qui se passe si ce dernier augmente ses prix.
D'après mes échanges avec des préfectures de district, plusieurs causes reviennent régulièrement :
- Le savoir est dispersé. L'informaticien connaît l'infrastructure, les services connaissent leurs applications, les prestataires connaissent leurs contrats. Personne n'a la vue d'ensemble.
- Les obligations arrivent séparément, mais retombent sur les mêmes personnes. KSC, KSeF, e-Doręczenia, le Registre central des contrats et l'obligation annoncée de système de classe EZD sont en pratique des évolutions du même circuit documentaire.
- Le service informatique est réduit. Deux ou trois personnes assurent le matériel, le réseau et le fonctionnement courant de l'administration. Elles n'ont pas le temps de piloter le choix d'un grand système.
- Les décisions se prennent sous la pression des délais. Il ne reste alors plus de temps pour comparer les offres, et la préfecture négocie en position de faiblesse.
Étape 1. Inventaire des systèmes et des contrats
La première étape n'est pas le choix d'un système, mais le recensement de l'existant. Un bon inventaire répond à des questions simples : quels systèmes fonctionnent dans chaque service, qui en est propriétaire, avec qui le contrat est-il conclu et jusqu'à quand, combien coûte la maintenance, quels systèmes échangent des données entre eux, et où se trouvent les points de défaillance uniques, c'est-à-dire les endroits où la panne d'un seul élément ou le départ d'une seule personne bloque le fonctionnement de l'administration.
L'inventaire dure de 2 à 6 semaines, reste en dessous du seuil des marchés publics et ne nécessite pas d'accès aux données des administrés. Il se conclut par une page de synthèse pour le starosta et le conseil exécutif du district, ainsi que par un ensemble de documents utilisés à chaque étape suivante. Détails : inventaire des systèmes informatiques.
Étape 2. Un plan des obligations tenant sur une page
Sur la base de l'inventaire, une page récapitule les obligations et les échéances. Pour chacune d'elles : qui en est responsable, quelle est la prochaine étape et pour quand.
- Système de classe EZD. Obligation annoncée ; selon les précisions du ministère de la Numérisation d'octobre 2026, l'échéance est repoussée au plus tôt à 2029, la réglementation étant encore en projet. Il convient de vérifier régulièrement cette information, le calendrier étant susceptible d'évoluer.
- KSC. La préfecture de district est une entité essentielle au sens de la loi sur le système national de cybersécurité ; certaines obligations ont leurs propres échéances. Par où commencer est détaillé dans l'article La loi KSC en préfecture de district.
- KSeF et e-Doręczenia. Ces dispositifs modifient le circuit des factures et du courrier, et touchent donc les mêmes processus que le système de classe EZD.
- Registre central des contrats. Il nécessite des informations sur les contrats que l'inventaire collecte de toute façon ; la démarche pas à pas est décrite dans l'article Registre central des contrats.
Le plan des obligations fonctionne comme un calendrier de travaux dans un bâtiment qui reste en service au quotidien. On ne peut pas refaire l'installation pièce par pièce, de manière indépendante. Il faut savoir ce qui passe par quels murs et organiser les travaux de façon à ce que l'administration continue de fonctionner en permanence.
Étape 3. Un budget défendable devant le Conseil de district
Un budget informatique présenté comme une seule ligne est difficile à défendre. C'est plus simple s'il est divisé entre l'obligation réglementaire (ce qui doit être fait en vertu de la loi) et l'investissement (ce que la préfecture entreprend pour fonctionner plus efficacement), avec, à côté, le coût de l'inaction : ce qui se passerait si rien n'était fait. Le projet de budget est préparé à l'automne, c'est donc le meilleur moment pour établir cette répartition. Plus de détails dans l'article Le budget informatique devant le Conseil.
Étape 4. Un pilote de la numérisation sans nouveau poste
Tout projet d'envergure a besoin d'un pilote : une personne qui veille à l'ensemble, aux délais et aux décisions. Dans une préfecture de district sans directeur informatique, ce rôle revient généralement au secrétaire, qui a cependant rarement le temps et l'expérience nécessaires pour choisir de grands systèmes. Plutôt que de créer un poste, on peut l'épauler par un consultant externe à temps partiel : quelqu'un qui, chaque semaine ou chaque mois, se réunit avec le secrétaire et le responsable informatique, tient un registre des projets et des risques, aide dans les échanges avec les prestataires et évalue leurs propositions de manière indépendante. Les décisions restent du côté de la préfecture.
Le responsable informatique est, dans ce dispositif, un allié, pas un objet de contrôle. Le registre des systèmes et la répartition du budget constituent les meilleurs arguments en faveur des ressources que cet informaticien réclame généralement depuis longtemps.
Exemple tiré de la pratique
J'ai observé le même mécanisme dans une grande collectivité territoriale (JST), où mon interlocuteur côté administration était le chef du service informatique. L'administration accumulait des applications supplémentaires, non reliées entre elles, censées soutenir le travail de différentes unités. Nous avons commencé par un inventaire de base des besoins et des systèmes existants. Sur cette base est née une feuille de route visant à optimiser les coûts des projets suivants, puis le socle d'une stratégie applicative, traduite en exigences technologiques : coût total de possession optimal, réduction du risque de vendor lock-in et plan de transfert des connaissances des prestataires vers l'équipe informatique interne.
L'administration a adopté des standards de modélisation des processus, de transfert de connaissances entre prestataires et de documentation des exigences et de l'architecture des systèmes, et a planifié sa stratégie applicative sur les dix années suivantes. Un constat a particulièrement surpris : des unités organisationnelles, disposant de leurs propres budgets et prérogatives, menaient en parallèle leurs propres initiatives informatiques. Elles développaient des silos et faisaient grimper les coûts de maintenance, alors que ces projets auraient pu, dès le départ, s'inscrire dans une stratégie unique et cohérente. Sans inventaire, personne n'aurait pu le voir.