Dans un système qui ne peut jamais s’arrêter, l’innovation la plus radicale n’est pas celle qui casse. C’est celle qui tient.
On demande aux directions IT deux choses qui se contredisent presque toujours. Aller plus vite. Et ne jamais tomber. Adopter le cloud, l’automatisation, l’intelligence artificielle générative, sans jamais interrompre la paie, le paiement, la chaîne de production ou le remboursement d’un assuré. Cette tension n’a rien d’un problème de communication. Elle est le problème central de toute direction des systèmes d’information depuis que le mot « legacy » existe.
Chez HN Services, cette tension porte un nom depuis 1983 : changer les codes. La formule a des allures de slogan. Elle décrit en réalité une méthode, éprouvée sur le mainframe, puis sur l’open systems, la supervision et, aujourd’hui, l’intelligence artificielle. Changer les codes ne signifie pas réécrire un système d’information à chaque cycle de mode technologique. Cela veut dire faire coexister, dans le même SI, ce qui a fait ses preuves depuis quarante ans et ce qui vient d’apparaître, sans jamais sacrifier l’un à l’autre.
Le mainframe n’est pas un problème à résoudre, c’est un actif à faire vivre
Le réflexe le plus répandu face à un système ancien est de vouloir s’en débarrasser. HN a fait un autre choix, dès l’origine : continuer d’investir dans le mainframe pendant que le reste du marché le déclarait obsolète. Cinq cents consultants orientés Mainframe en Europe, mille deux cents sur l’Open Systems, formés en continu par HN Institut depuis 1989 : ce socle existe précisément parce que la pénurie de compétences sur ces technologies n’a jamais été traitée comme une fatalité, mais comme un problème d’ingénierie ordinaire, qu’on résout en formant plutôt qu’en fuyant.
Changer les codes commence là : reconnaître qu’un système vieux de quarante ans qui traite encore, chaque jour, des millions d’opérations critiques n’est pas un problème à régler dans l’urgence. C’est un actif qu’il faut continuer de faire vivre, avec la même exigence que n’importe quel système neuf.
De la supervision à l’expérience : changer de couche sans couper le courant
La supervision IT illustre la même logique, à une autre échelle de temps. Elle a longtemps consisté à regarder des voyants rouges ou verts. Elle est devenue observabilité, en ajoutant la capacité à comprendre un système à partir de ce qu’il produit plutôt qu’à partir de ce qu’on lui a demandé de surveiller. Elle intègre aujourd’hui l’AIOps, qui ajoute une couche prédictive sans supprimer la précédente. Et elle s’oriente désormais vers l’expérience pilotée : mesurer non plus seulement la disponibilité d’une infrastructure, mais ce qu’elle produit réellement pour l’utilisateur final, parce qu’un système peut afficher tous ses indicateurs au vert et rester, pour celui qui l’utilise, lent ou inutilisable.
Trois évolutions en quinze ans. Aucune n’a consisté à jeter la précédente. Chacune s’est construite sur celle d’avant, comme des couches qui s’additionnent plutôt que des versions qui s’annulent. C’est exactement ce que changer les codes veut dire appliqué à une discipline entière : on ne remplace pas une brique qui fonctionne, on l’enrichit tant qu’elle a quelque chose à apporter.
L’intelligence artificielle : une innovation qu’on cadre avant de la déployer
L’IA générative est aujourd’hui le meilleur test de cette philosophie, parce qu’elle est aussi le meilleur endroit pour la trahir. La tentation est grande de brancher un copilote sur chaque poste de travail avant même d’avoir répondu à trois questions simples : qui gouverne les usages, où vont les données, et que se passe-t-il le jour où le modèle se trompe.
HN a choisi de cadrer avant de construire. Prendre le contrôle de l’usage de l’IA sans brider l’innovation, ce n’est pas un compromis timide. C’est la même discipline appliquée à une technologie de trois ans plutôt qu’à un mainframe de quarante : un cadrage des usages, une preuve de concept avant le déploiement, une gouvernance et une charte d’usage avant la généralisation. Les équipes qui accompagnent nos clients vers une IA privée, sobre et souveraine savent, par expérience, qu’une technologie mal gouvernée finit toujours par coûter plus cher que le retard qu’elle était censée rattraper.
Ce que changer les codes veut dire, au fond
Aucune de ces trois histoires n’est une histoire de rupture. Ce sont des histoires de séquence : simplifier avant d’automatiser, unifier avant d’industrialiser, cadrer avant de déployer. Sylvain Roiz, qui pilote la production IT chez HN, l’écrivait à propos de la supervision : elle n’est pas qu’une fonction support, c’est un métier d’avenir, au cœur de la performance digitale. La même conviction vaut pour l’ensemble du système d’information. La vraie transformation n’est pas celle qui casse le service pour prouver qu’elle existe. C’est celle qui reste invisible pour l’utilisateur, précisément parce qu’elle a été pensée pour ne jamais l’exposer à la bascule.
Changer les codes, chez HN, n’est donc pas une promesse d’audace. C’est une promesse de méthode. Le risque, pour une DSI en 2026, n’est plus d’être trop lente à adopter une nouvelle technologie. Il est d’en adopter une sans avoir organisé sa cohabitation avec tout ce qui, dans le système d’information, continue de faire tourner l’entreprise pendant qu’on l’améliore.
La question à se poser n’est donc pas : sommes-nous prêts à changer ? Elle est : savons-nous encore changer sans rien casser ?