Dans un groupe multi-sites, on vit avec une tentation permanente: laisser chaque établissement “faire comme il veut” parce que “ils connaissent leur réalité”. Et on vit avec une autre tentation, tout aussi permanente : tout uniformiser parce que “sinon c’est ingérable”. Les deux réflexes partent d’une bonne intention. Les deux finissent souvent par coûter cher. Pas seulement en euros. En énergie, en temps perdu, en irritants quotidiens, et parfois en risques.
Chez emeis, la complexité n’est pas un concept. C’est une géographie. Des sites, des équipes, des métiers, des contraintes réglementaires, des habitudes locales, des fournisseurs historiques, des urgences qui ne ressemblent pas à des projets. On peut se raconter que cette diversité est une richesse. C’est vrai. Mais c’est aussi un multiplicateur de friction, surtout quand l’outillage numérique devient hétérogène au point de transformer chaque support, chaque formation, chaque changement en cas particulier.
Le problème n’est pas “standardiser”. Le problème, c’est comment on standardise.
La mauvaise standardisation, on la reconnaît vite. Elle arrive sous forme de catalogue imposé, de migration massive, de décisions prises loin du terrain, puis d’une période où tout le monde “s’adapte”, c’est-à-dire contourne. Elle produit des exceptions, puis des exceptions d’exceptions. Elle se termine avec un SI officiellement homogène et officieusement bricolé. Et le terrain garde une impression durable : on lui a retiré des marges de manœuvre sans lui rendre du temps.
La bonne standardisation, elle, fait l’inverse. Elle commence par une question simple et presque provocante : qu’est-ce qui doit être identique partout, parce que ça protège ou ça libère? Et qu’est-ce qui doit rester modulable, parce que ça relève du soin, du contexte, du rythme local ?
Pour un DSI, la frontière utile est souvent “invisible vs visible”.
- Invisible, c’est tout ce que les équipes ne devraient jamais avoir à ressentir : identité, sécurité, réseau, postes maîtrisés, sauvegardes, supervision, gestion des terminaux, patching, socles applicatifs, interopérabilité de base. Là, l’hétérogénéité ne crée pas de valeur. Elle crée des pannes, des trous de sécurité, des délais, des coûts, et une fatigue collective.
- Visible, c’est ce qui touche au geste, au flux de travail, à l’expérience des équipes et des patients : les écrans, les formulaires, les parcours, les priorités de saisie, les notifications, les arbitrages. Là, imposer un standard sans finesse devient vite une agression. Parce qu’on touche au “comment je travaille” dans un univers où le temps est compté et la charge émotionnelle réelle.
Ce qui marche, dans la vraie vie, c’est de standardiser le socle et de modulariser la surface.
Standardiser le socle, c’est assumer qu’un groupe multi-sites ne peut pas survivre longtemps avec 15 variantes de poste de travail, 12 façons de gérer les accès, 8 fournisseurs réseau, et des règles de sécurité “à la tête du client”. Dans la santé, le coût de cette dispersion ne se limite pas au budget IT. Il se paye en indisponibilités, en accès non maîtrisés, en incidents, en temps perdu pour “faire marcher”. Le socle doit être boring. Robuste. Prévisible.
Modulariser la surface, c’est accepter qu’un établissement n’a pas besoin d’être un clone pour être compatible. On peut définir des standards d’outils et des standards de données, tout en laissant des variations d’usage, de paramétrage, de séquencement, là où ça fait sens. On peut fixer des “garde-fous” (ce qui est non négociable) et laisser de la latitude sur le reste. La nuance est clé : la diversité doit être un choix explicite, pas un accident historique.
Mais il y a une condition : la gouvernance. Sans gouvernance, un standard devient soit une dictature, soit une passoire. Avec la bonne gouvernance, il devient un contrat. Le contrat peut tenir en trois objets simples :
D’abord, un catalogue de standards lisible : ce qui est obligatoire (socle), ce qui est recommandé, ce qui est local. Pas un document de 80 pages. Un cadre que les directeurs d’établissement et les équipes comprennent. Ensuite, une logique d’exception adulte : on peut déroger, mais pas gratuitement. Une exception a un motif, une durée, un propriétaire, et un plan de retour. Sinon ce n’est pas une exception, c’est un nouveau standard caché.
Enfin, un cercle de terrain qui arbitre avec l’IT : pas un comité théorique. Un dispositif où des représentants d’établissements, des métiers et l’IT tranchent ensemble les sujets “surface”, en protégeant l’essentiel : la sécurité, la continuité, et le temps de soin.
Le bénéfice, c’est moins d’attente, moins d’irritants, moins d’incertitude. Des arrivées plus rapides. Des changements plus simples. Des incidents mieux contenus. Des équipes support qui ne réapprennent pas le même problème dans 40 variantes. Et, surtout, des soignants qui récupèrent quelques minutes ici et là parce qu’ils ne se battent plus avec l’outil. Dans un secteur où le temps est la ressource la plus rare, c’est un gain immense.
Standardiser sans déshumaniser, c’est refuser le faux choix entre “liberté locale” et “contrôle central”. C’est choisir une architecture de confiance : un socle commun qui protège, et une surface adaptable qui respecte. C’est faire de l’IT un facteur de cohérence, pas un facteur de lassitude.
Et c’est, au fond, une manière de dire aux équipes : on ne standardise pas pour simplifier la vie de l’IT. On standardise pour simplifier la vôtre.
