Ce qu'on découvre en premier, presque à chaque fois, c'est que le portefeuille officiel ne représente qu'une partie de ce qui se passe réellement. Il y a les projets qui figurent dans les plans. Et il y a tout le reste ; les initiatives lancées par un responsable métier sans en référer à la DSI, les micro-projets que les équipes mènent en parallèle de leurs activités officielles parce qu'un besoin urgent est apparu, la dette technique accumulée sur des systèmes que personne n'a officiellement la charge de maintenir. Ce portefeuille invisible est souvent plus volumineux que le portefeuille visible.

Sur une mission concrète, l'inventaire exhaustif réalisé en début de mandat a révélé un écart de près de 40% entre les projets officiellement suivis et la réalité des travaux en cours. Des équipes qui passaient 30% de leur temps sur des sujets non référencés dans aucun plan. Ce n'est pas de la mauvaise volonté. C'est le signe que le portefeuille officiel ne répond pas suffisamment vite aux besoins réels.

Quand les équipes contournent le système de gouvernance, c'est souvent parce que ce système est trop lent ou trop rigide pour elles. C'est un signal d'organisation, pas un problème de discipline.

Avant même de regarder les projets, la première question à poser est celle des objectifs. À quoi ce portefeuille doit-il servir, concrètement, dans les dix-huit prochains mois ? Quels sont les deux ou trois objectifs stratégiques de l'organisation, et comment chaque projet du portefeuille y contribue-t-il ? Cette question semble évidente. Dans la réalité, elle produit très souvent un silence inconfortable. Parce que les projets se sont accumulés par opportunité, par demande des métiers, par décision politique, sans qu'on ait jamais vérifié leur cohérence avec une trajectoire stratégique. On se retrouve avec un portefeuille qui consomme 100% des ressources disponibles sur des sujets dont certains ne servent aucun objectif prioritaire.

La première chose à faire pour piloter les coûts à l'échelle d'un portefeuille, c'est de distinguer trois natures de coûts qui sont presque toujours mélangées dans une seule enveloppe. Les coûts de run d'abord, le maintien en condition opérationnelle, les licences, l'infrastructure, le support. Les coûts de build ensuite, les projets d'évolution et de transformation. Et la troisième catégorie, celle que la plupart des organisations n'ont pas formalisée ; le coût de la dette technique. Ce que l'on paie chaque mois en maintenance corrective sur des systèmes vieillissants, en temps perdu sur des processus mal outillés, en risque accepté faute d'investissement. Cette troisième ligne ne figure dans presque aucun budget, et pourtant elle s'accumule et finit par peser sur tout le reste.

Sur un périmètre d'infrastructure mutualisée desservant plusieurs dizaines de milliers d'utilisateurs finaux, la première chose que nous avons faite a été un inventaire physique complet. Personne ne l'avait fait sérieusement depuis des années. Nous avons trouvé des équipements allumés depuis plus de dix ans qui ne servaient plus à rien. Des équipements critiques partagés entre plusieurs projets sans que les dépendances soient documentées nulle part. Des doublons de facturation, deux contrats de maintenance couvrant les mêmes actifs, renouvelés automatiquement chaque année sans que quiconque ne les rapproche.

Ce travail de fond, pas une décision stratégique brillante, a permis de réduire de moitié les coûts de maintenance annuels et de rationaliser l'infrastructure de 80%. Ce que cela démontre ; les gains les plus significatifs ne viennent pas des grandes réorganisations. Ils viennent d'un regard honnête sur ce qu'on a réellement.

La dette technique est souvent mal présentée aux décideurs. On leur parle de technologies obsolètes, de versions non supportées, de code legacy, et ils ne savent pas quoi en faire. Ce qu'il faut leur présenter, c'est une qualification financière et stratégique.

Je distingue cinq types de dette selon leur nature. La dette d'infrastructure ; matériel en fin de vie, systèmes d'exploitation sans support éditeur. La dette applicative ; frameworks obsolètes, dépendances non maintenues. La dette architecturale, souvent la plus coûteuse et la moins visible ; les couplages forts entre systèmes qui font qu'on ne peut plus rien faire évoluer sans toucher à tout. La dette de données ; référentiels mal gouvernés, doublons, données sans propriétaire. Et la dette de sécurité ; composants avec des vulnérabilités connues non corrigées.

Pour chaque composant en dette, je pose les mêmes quatre questions. Quel est le risque de défaillance à douze mois ? Quel est l'impact si ça tombe ? Quel est le coût de remédiation aujourd'hui ? Et quel est le coût de l'inaction dans deux ans, sachant qu'on aura probablement continué à construire dessus entre-temps ? Ce dernier chiffre est souvent le plus révélateur. Une dette de 200 000 euros à traiter aujourd'hui peut coûter 800 000 euros dans deux ans.

Un composant que personne ne touche depuis huit ans et que personne ne comprend vraiment est presque toujours un problème en attente de se manifester. La stabilité apparente n'est pas un indicateur de santé. C'est parfois le signe qu'on a arrêté d'y toucher parce qu'on en a peur.

La première tentation, c'est de déployer un référentiel. C'est la mauvaise réponse, et je l'ai faite assez tôt dans ma carrière pour l'avoir payée. Une organisation qui n'a pas de gouvernance formelle ne manque pas de méthode. Elle manque de confiance dans les méthodes qu'on lui a déjà proposées et qui n'ont pas fonctionné, ou de compréhension de pourquoi ça pourrait changer quelque chose à ce qu'elle vit au quotidien.

Sur ce point, la méthode est simple ; commencer par identifier les deux ou trois dysfonctionnements qui coûtent le plus cher à l'organisation en ce moment, pas sur le papier, dans la vie des équipes. Des incidents qui se répètent sans qu'on sache pourquoi, des demandes qui se perdent, des réunions qui se terminent sans décision. Je commence par formaliser exactement ces processus-là, en travaillant avec les équipes concernées, pas en leur imposant un référentiel depuis l'extérieur. Quand les gens voient qu'un processus simple résout un problème qui les agaçait depuis des mois, la dynamique change. On peut ensuite construire là-dessus.

Une procédure non suivie est pire qu'une absence de procédure ; elle crée une illusion de conformité et décourage les équipes d'y croire à nouveau.

C'est la situation la plus éprouvante, et je serais malhonnête si je disais avoir toujours su comment la gérer. Ce que j'ai appris, c'est que dans les institutions publiques et les grandes organisations, la décision politique n'est pas un dysfonctionnement. C'est une réalité du système. Les projets s'inscrivent dans des agendas, des équilibres de pouvoir, des contraintes de calendrier qui n'ont parfois rien à voir avec la logique technique ou économique.

Ma position ; jouer le rôle de conseil jusqu'au bout. Documenter l'analyse, les risques identifiés, les alternatives possibles. Si la décision va contre ce que je recommande, le formuler clairement par écrit. Non pour se couvrir, mais pour que les risques soient conscientisés par ceux qui décident. Ensuite, si la décision est prise, l'exécuter loyalement. Il m'est arrivé une fois de demander à être relevé d'une mission parce que je considérais que les conditions d'un travail sérieux n'étaient plus réunies. Un directeur qui sabote silencieusement une décision avec laquelle il n'est pas d'accord n'est utile à personne.

L'ambition de la direction générale est rarement calibrée sur les capacités réelles, en budget, en temps, en compétences disponibles. Ce n'est pas de la mauvaise foi. C'est simplement que les dirigeants voient ce qu'il faudrait faire, pas ce qu'il est possible de faire avec ce qu'on a.

L'erreur à éviter ; accepter un mandat avec un budget insuffisant en espérant que ça se régulera en cours de route. J'ai vu trop de projets condamnés dès le départ parce que personne n'avait eu le courage de le dire clairement au moment de la commande. Le non-dit initial devient le conflit final, souvent dix-huit mois plus tard, quand il n'est plus possible de l'éviter.

La démarche ; mettre la réalité sur la table le plus tôt possible, avec des scénarios. Voici ce que vous demandez, voici ce que ça nécessite réellement, voici trois options en fonction du budget disponible. Une première phase réaliste qui démontre de la valeur et crée les conditions pour la suivante est presque toujours préférable à un programme ambitieux qui s'effondre à mi-parcours.

Une transformation trop rapide pour les compétences disponibles ne transforme pas. Elle crée du chaos, de la désillusion, puis un retour au point de départ avec en plus la conviction que la transformation ne peut pas marcher ici.

L'élément intégré systématiquement ; un volet formation et montée en compétence qui n'est pas une annexe au projet, mais un livrable de premier rang. Le critère de succès d'un déploiement ne doit pas être "le système est installé". Il doit être "les équipes peuvent l'utiliser et le maintenir sans nous". Cette distinction change tout à la façon dont on conçoit un projet.

Sur la question des prestataires, c'est là où je suis le plus exigeant contractuellement. Les prestataires ont peu d'intérêt naturel à rendre leurs clients autonomes. Sans mécanismes explicites de transfert, des sessions de formation documentées, un plan de réversibilité formalisé, des critères de validation des acquis, le transfert de compétences n'a pas lieu. J'ai vu des organisations encore dépendantes de prestataires sur des systèmes déployés cinq ans plus tôt.

Sur ce sujet, ma position a changé au fil des années. Je suis passé d'une posture de "comment convaincre" à une posture de "comment comprendre". La résistance au changement est rarement irrationnelle. Elle exprime quelque chose de réel ; une crainte de perte de compétence, la mémoire d'un projet passé qui s'est mal terminé, une méfiance envers une direction qui a promis beaucoup et tenu peu, parfois simplement une surcharge de travail qui fait que ce changement de plus arrive au mauvais moment.

La première étape ; cartographier les résistances avant de commencer, pas par des enquêtes formelles, mais par des conversations directes avec les équipes, sans l'agenda du projet dans la salle. Non pas "êtes-vous favorable au changement ?" mais "qu'est-ce qui vous préoccupe dans ce changement, qu'est-ce qui doit absolument être préservé ?". Ces questions produisent des informations que les analyses d'impact ne donnent pas. Souvent, elles révèlent des préoccupations légitimes que le projet n'avait pas prises en compte.

J'identifie systématiquement les personnes influentes dans l'organisation, pas nécessairement les managers hiérarchiques, mais celles que les autres écoutent. Un changement porté par des pairs a infiniment plus de chances d'être adopté qu'un changement imposé par la direction.

Sur la digitalisation d'un système de maintenance industrielle, nous avions livré une solution techniquement solide. La GMAO était bien paramétrée, les données bien migrées, l'architecture correcte. Trois mois après le lancement, le taux de saisie réelle par les techniciens de maintenance était de 23%. Les tableaux de bord de maintenance prédictive, pour lesquels l'organisation avait investi plusieurs centaines de milliers d'euros, fonctionnaient sur du vide.

En passant du temps dans les ateliers plutôt que dans les salles de réunion, j'ai compris trois choses que les rapports d'avancement ne montraient pas. Les techniciens ne voyaient pas le lien entre leur saisie et une quelconque utilité pour eux. Les terminaux fournis étaient inadaptés aux conditions physiques de leur travail, la graisse, la poussière, les gants. Et les chefs d'équipe n'avaient pas été formés pour valoriser la saisie dans leurs briefings quotidiens.

Nous avons remplacé les terminaux par des modèles adaptés au terrain, créé un tableau d'affichage en atelier montrant en temps réel les bénéfices concrets issus des saisies, et travaillé spécifiquement avec les chefs d'équipe sur leur rôle dans l'adoption. Six mois plus tard, le taux de saisie était à 78%. La première alerte de maintenance prédictive sur une pompe critique a évité un arrêt de ligne évalué à 200 000 euros.

On avait bien conçu le système. On avait mal conçu l'adoption. Ce sont deux projets différents, et les traiter comme un seul est l'une des erreurs les plus fréquentes et les plus coûteuses dans les projets de transformation.

Sur un projet d'insourcing particulièrement complexe, nous nous sommes retrouvés face à une double résistance. Le prestataire sortant appliquait un minimum syndical sur les transferts de documentation. Et certaines personnes clés de ce prestataire freinaient activement, parce qu'elles craignaient pour leur emploi.

Après analyse précise des compétences réellement irremplaçables, des personnes qui maîtrisaient des systèmes anciens sur lesquels il n'existait pratiquement plus de formation disponible sur le marché, j'ai suggéré à mon client de les recruter. L'argument était simple ; leur résistance venait d'une peur concrète de perdre leur source de revenus. En leur offrant une place dans l'organisation cliente, on transformait le frein le plus actif en transmission de compétences. Le client a accepté. En quelques semaines, la dynamique du projet avait complètement changé.

En travaillant au sein des représentations françaises de grandes corporations américaines, à la direction informatique européenne d'un grand groupe industriel puis au sein d'une ESN internationale de premier rang, j'ai observé une culture de gouvernance radicalement différente de ce que je connaissais du tissu d'entreprises françaises. Ces organisations ne choisissaient pas entre les référentiels. Elles les articulaient. Non par sophistication intellectuelle, mais par logique économique concrète ; chaque cadre ouvre des portes différentes. Une certification ISO 27001 crédibilise l'offre sur des marchés qui l'exigent. La conformité COSO rassure les commissaires aux comptes et les investisseurs institutionnels. La maturité ITIL réduit les coûts opérationnels de façon mesurable. PMBOK et Prince2 structurent le pilotage de programme de façon défendable devant n'importe quel conseil d'administration. Ces organisations avaient compris que la gouvernance des systèmes d'information n'est pas un coût de conformité. C'est une infrastructure de compétitivité.

Au sein du groupe industriel, deux dimensions supplémentaires structuraient la culture opérationnelle d'une façon que je n'avais jamais observée dans des organisations françaises équivalentes. Le Lean et le Six Sigma étaient une obligation pour l'ensemble des responsables, pas une initiative volontaire réservée à la production. Tout manager était formé, toute amélioration de processus devait être conduite selon ces disciplines. Et la conformité Sarbanes-Oxley, la loi américaine de 2002 sur la gouvernance financière des entreprises cotées, imposait une rigueur documentaire et un contrôle interne qui remontaient directement dans les systèmes d'information ; chaque processus critique devait être documenté, testé, et son efficacité démontrée aux auditeurs externes. Ces cadres n'étaient pas vécus comme des lourdeurs. Ils étaient compris comme des garanties opérationnelles ; la garantie que les objectifs fixés seraient atteints, que les écarts seraient détectés avant de devenir des crises, et que la conformité serait démontrable à tout moment sans travail d'urgence. Ce contraste entre ces pratiques et celles du tissu d'entreprises françaises de l'époque a fondé ma conviction que la gouvernance transdisciplinaire n'est pas une spécificité culturelle. C'est une discipline accessible à toute organisation qui accepte de traiter la rigueur méthodologique comme un avantage compétitif plutôt que comme une contrainte administrative. À ce jour, la plupart des institutions publiques françaises n'ont pas encore atteint le niveau de maturité ITIL que ces environnements appliquaient en routine, encore moins l'alignement des cadres COBIT, COSO, TOGAF, Lean, Six Sigma, PMBOK et Prince2. Ce n'est pas une critique ; c'est un constat qui explique pourquoi ce chantier reste entier, et pourquoi il est urgent.

COBIT 2019 répond à la question de la gouvernance et du management des SI. Il permet de cascader les objectifs stratégiques de l'organisation jusqu'aux objectifs opérationnels IT, en passant par une logique de droits de décision clairement attribués. Son apport essentiel ; rendre les décisions IT défendables devant un COMEX, parce qu'elles sont reliées à des objectifs que tout le monde a validés.

COSO intervient à un niveau différent. C'est le cadre du contrôle interne d'entreprise. Ses cinq composantes, environnement de contrôle, évaluation des risques, activités de contrôle, information et communication, pilotage, donnent un langage commun avec les auditeurs financiers et les directions générales qui ne parlent pas le vocabulaire IT. Quand une recommandation de gouvernance des SI est formulée dans le cadre de COSO, elle devient audible par des interlocuteurs qui l'auraient ignorée en termes de maturité COBIT.

TOGAF répond à la question "quel SI construire pour que l'organisation reste capable d'évoluer dans cinq ans ?". Il structure l'architecture d'entreprise sur quatre niveaux ; l'architecture métier, les processus et capacités organisationnelles ; l'architecture des données ; l'architecture des applications ; et l'architecture technique. Sur le projet de transformation d'un groupe industriel gérant plus de 80 000 équipements sur plusieurs sites, c'est cette démarche architecturale qui a permis de concevoir l'intégration des systèmes de supervision industrielle, de la GMAO, des ERP et des outils décisionnels avec une cohérence d'ensemble, plutôt que de les connecter point à point au fil des besoins.

ITIL 4 structure les pratiques de gestion des services au quotidien. Il ne certifie pas des organisations mais des individus, et il ne définit pas des exigences mais des pratiques. C'est précisément pour ça qu'il est complémentaire d'ISO 20000, qui elle fixe des exigences certifiables. ITIL dit "comment faire", ISO 20000 dit "quoi atteindre".

La gouvernance des systèmes d'information ne vaut rien si les projets qui la mettent en oeuvre sont mal pilotés. C'est là qu'interviennent les méthodes de management de projet, et en particulier les deux références mondiales que sont PMBOK et Prince2. Elles ne s'opposent pas. Elles répondent à des contextes et à des besoins différents, et leur articulation avec les cadres de gouvernance est aussi nécessaire que celle de COBIT avec ITIL.

PMBOK, le Project Management Body of Knowledge publié par le PMI, est un référentiel de bonnes pratiques qui couvre l'ensemble du cycle de vie d'un projet à travers dix domaines de connaissance ; intégration, périmètre, calendrier, coûts, qualité, ressources, communications, risques, approvisionnements, parties prenantes. Son approche est celle d'un cadre complet et adaptable, qui définit ce qu'un chef de projet doit maîtriser sans imposer une séquence rigide. Dans sa version la plus récente, PMBOK 7 a évolué vers une logique de principes et de domaines de performance, intégrant les approches agiles aux côtés des approches prédictives traditionnelles. C'est le référentiel de facto dans les environnements américains et internationaux, adopté massivement dans les groupes du Fortune 100.

Prince2, né dans le secteur public britannique et largement adopté en Europe continentale et dans les institutions internationales, repose sur une logique différente. C'est une méthode structurée, avec des rôles précisément définis, des étapes séquencées, des processus de décision formalisés à chaque phase. Son apport essentiel ; la justification continue du projet par un business case qui doit rester valide du lancement à la clôture. Si le business case ne tient plus, le projet doit être arrêté ou revu. Cette rigueur, qui peut sembler contraignante, est précisément ce qui manque dans la majorité des projets IT qui dérivent. Prince2 impose de répondre à la question "pourquoi continue-t-on ce projet ?" à chaque étape, pas seulement au démarrage.

Dans ma pratique, j'utilise ces deux méthodes de façon complémentaire selon le contexte. PMBOK pour la richesse de ses domaines de connaissance et sa flexibilité d'adaptation à des environnements complexes et multiculturels. Prince2 pour la rigueur de sa gouvernance de projet, en particulier dans les contextes institutionnels ou dans les programmes multi-parties prenantes où les rôles et les responsabilités doivent être définis sans ambiguïté. Sur le programme de transformation d'un groupe industriel couvrant 80 000 équipements sur plusieurs sites et plusieurs années, la structure de gouvernance de programme s'est appuyée sur la logique Prince2 pour la définition des rôles et des étapes de décision, et sur PMBOK pour la gestion des domaines complexes comme les approvisionnements internationaux et la gestion des risques multi-sites.

Ce qui unit ces deux méthodes à l'ensemble des cadres de gouvernance décrits dans cet article, c'est leur contribution à la cascade des objectifs. Un projet bien piloté selon PMBOK ou Prince2 peut démontrer à tout moment sa contribution aux objectifs stratégiques formalisés dans COBIT, sa conformité aux contrôles internes définis par COSO, sa cohérence avec l'architecture cible tracée par TOGAF, et la qualité des services qu'il délivre selon les pratiques ITIL. Sans cette connexion, les méthodes projet restent des outils de planification isolés. Avec elle, elles deviennent des leviers de transformation organisationnelle durable.

Les problèmes les plus difficiles à résoudre dans les organisations sont ceux qui se trouvent aux intersections entre les disciplines. La gouvernance des données est à la fois un sujet IT, un sujet juridique avec le RGPD, un sujet de performance métier et un sujet de risque. Aucun référentiel pris seul ne couvre toutes ces dimensions.

Quand une organisation a des conflits permanents entre ses directions métier et sa DSI, le problème n'est pas technique. C'est souvent un problème de droits de décision non clarifiés, que COBIT adresse directement. Quand un programme de transformation échoue à être adopté, ce n'est pas un problème de méthode projet. C'est souvent un problème d'architecture organisationnelle que TOGAF permet de diagnostiquer. Quand un audit de sécurité révèle des failles structurelles, elles viennent presque toujours d'une gouvernance des accès ou des données mal définie, que l'articulation ISO 27001 et COBIT permet de corriger durablement. Et quand un projet dérape au-delà de tout budget raisonnable, c'est rarement un problème de compétences techniques ; c'est presque toujours l'absence d'une méthode de pilotage qui impose la justification continue, la revue des risques et la transparence sur les écarts.

J'ai vu des organisations qui maîtrisaient ITIL mais ne savaient pas piloter leurs projets de transformation, produisant des services de qualité sur des systèmes qui allaient dans la mauvaise direction. J'en ai vu d'autres qui pilotaient leurs projets avec rigueur mais sans cadre de gouvernance, livrant dans les délais des solutions que personne n'adoptait parce qu'elles ne correspondaient à aucun objectif partagé. La maturité organisationnelle, c'est précisément la capacité à faire fonctionner ces cadres ensemble, en sachant quel outil répond à quelle question au bon moment.

Un indicateur concret de la valeur de cette articulation ; la méthode transverse de gouvernance que j'avais conçue au sein d'une ESN française de premier rang, combinant CMDB, ITAM et GRC dans un outil intégré et une démarche documentée, a été reconnue par l'État français comme éligible au Crédit Impôt Recherche à hauteur de 330 000 euros. Ce n'est pas un argument d'autorité. C'est un signal ; quand une administration fiscale reconnaît qu'une méthode de gouvernance constitue une innovation au sens de la recherche et du développement, c'est que cette méthode n'était pas la simple application de référentiels existants. C'était leur articulation originale dans un cadre opérationnel nouveau, produisant une valeur que les référentiels pris isolément n'auraient pas permis d'atteindre.

J'étais responsable européen du support d'une plateforme de télésurveillance déployée dans des postes de commandement sécurité, des environnements où mes clients géraient la surveillance d'établissements bancaires, d'infrastructures sensibles, de forces de sécurité. Mon périmètre ; l'infrastructure serveur qui agrège toutes les remontées, et les protocoles de supervision adaptés au niveau d'exigence de chaque client.

Ce que cette expérience m'a appris de manière irréversible, c'est que les défaillances de sécurité les plus coûteuses ne venaient jamais des équipements. Elles venaient des habitudes des personnels, des procédures mal appliquées, des codes partagés avec des tiers de confiance, des opérateurs qui désactivaient des alertes jugées trop fréquentes.

Trois principes que j'ai intégrés à cette époque et qui structurent encore ma pratique aujourd'hui. La sécurité se conçoit en couches, chacune supposant que la précédente peut défaillir. Le maillon faible est presque toujours humain. Et la détection ne vaut rien sans la réponse ; le délai entre l'alerte et l'intervention efficace est l'indicateur qui compte, pas le nombre de systèmes déployés.

La première condition d'efficacité d'un SOC, et la moins souvent remplie, c'est que le SI surveillé soit lui-même connu et cartographié avec précision. Un SIEM qui corrèle des événements sans contexte ne peut pas produire des alertes pertinentes. Un analyste qui reçoit une alerte sur un composant dont il ne sait pas si c'est critique ou anecdotique pour l'activité ne peut pas prioriser correctement.

Avant de déployer un SOC, il faut disposer d'une CMDB consolidée, d'un catalogue de services qui mappe les composants IT aux fonctions métier, et d'une connaissance des workflows normaux de l'organisation. Sans ça, on installe un système de détection dans le noir.

J'ai vu des SOC paralysés par leurs propres outils. Des SIEM mal configurés qui produisaient des milliers d'alertes par jour, dont 95% étaient des faux positifs. Les analystes finissent par traiter toutes les alertes avec la même urgence faible, y compris celles qui méritent une réponse immédiate. C'est l'alert fatigue, et c'est l'une des causes les plus fréquentes d'incidents graves dans des organisations qui pensaient être protégées.

Ce que j'ai appris à faire en premier ; définir les cinq ou six scénarios d'attaque les plus probables dans le secteur et pour ce type d'organisation. Ransomware, phishing ciblé, compromission de comptes à privilèges, attaque sur la chaîne d'approvisionnement. Ce sont ces scénarios qui définissent les sources de logs à collecter, les règles de corrélation à écrire, et les playbooks de réponse à automatiser. La technologie vient après, pas avant.

La gestion des identités et des accès est presque toujours le premier chantier que je recommande, parce que c'est là que le rapport entre l'investissement et la réduction de surface d'attaque est le plus favorable. Sur un périmètre IAM couvrant plusieurs dizaines de milliers d'utilisateurs sur une zone internationale, ce que j'ai trouvé de manière systématique ; un écart considérable entre la politique définie centralement et la réalité appliquée localement. Des comptes avec des droits bien au-delà de ce que leur rôle justifiait, hérités de contextes anciens et jamais révisés. Des comptes de service dormants depuis des années, conservant des accès à des systèmes critiques. Des accès prestataires non révoqués à la fin de missions terminées depuis des mois.

La revue des droits d'accès n'est pas un projet qu'on fait une fois. C'est un processus permanent, trimestriel au minimum pour les comptes à privilèges. La première revue produit presque toujours des découvertes qui justifient à elles seules l'investissement.

La difficulté fondamentale de la sécurité dans les environnements industriels est culturelle avant d'être technique. Dans un environnement de production en continu, un arrêt non planifié peut coûter plusieurs dizaines ou centaines de milliers d'euros par heure. Les équipes opérationnelles ont développé une culture de "ne pas toucher à ce qui fonctionne" qui est parfaitement rationnelle dans leur logique, et dangereuse du point de vue de la sécurité.

Sur les audits de sites industriels que j'ai conduits, l'une des découvertes les plus fréquentes et les plus préoccupantes est l'absence de segmentation entre les réseaux de supervision industrielle et les réseaux bureautiques. Un système SCADA qui parle directement au réseau bureautique, c'est une voie d'entrée potentielle pour un attaquant depuis un simple poste de travail. Et dans la grande majorité des sites audités, il n'existait aucun plan documenté de réponse à la question "que fait-on si le système de supervision est compromis ?".

Il existe une croyance tenace dans les organisations ; les problèmes de sécurité et d'efficacité opérationnelle sont des problèmes techniques qui appellent des solutions techniques. On achète un outil, on déploie une plateforme, on signe un contrat avec un éditeur, et le problème est censé se résoudre. C'est ce que j'appelle le technosolutionnisme, et c'est l'une des postures les plus dangereuses qu'une organisation puisse adopter.

Bruce Schneier l'a formulé avec une clarté que j'aurais aimé trouver plus tôt dans ma carrière ; la sécurité est un processus, pas un produit. Les produits fournissent une protection, mais le processus est la façon dont on les utilise pour maintenir la sécurité. Autrement dit, les outils techniques sont des composants nécessaires mais non suffisants. Sans les processus, les compétences et la culture pour les utiliser correctement, ils deviennent des coquilles vides. Un pare-feu mal configuré ne protège de rien. Un SIEM dont les alertes ne sont pas traitées ne sert à rien. Une authentification multifacteur non déployée sur les comptes critiques reste lettre morte.

Une gouvernance des systèmes d'information technosolutionniste, sans bonnes pratiques ancrées dans l'organisation, est elle-même un point de défaillance unique. C'est une réalité que j'ai observée sur plusieurs centaines de sites industriels audités et dans des dizaines d'organisations publiques et privées.

La vague actuelle d'enthousiasme autour de l'intelligence artificielle illustre le technosolutionnisme dans sa forme la plus récente. Les discours sur les agents IA qui codent des applications entières en cinq minutes, qui remplacent des équipes entières de développeurs, qui "pensent à votre place" partagent tous la même logique ; l'outil va régler le problème.

Ce qui est occulté dans ces discours, c'est tout ce que l'outil ne fait pas. Elle ne définit pas les besoins métier. Elle ne questionne pas si le problème qu'on lui demande de résoudre est le bon problème. Elle ne gère pas les droits d'accès aux données qu'elle manipule. Elle ne vérifie pas que le code généré respecte les exigences de sécurité, de conformité réglementaire, ou d'architecture du SI existant. Elle ne s'assure pas que les équipes qui vont utiliser et maintenir ce qui a été créé en comprennent le fonctionnement. Et elle ne prend aucune responsabilité quand ça tourne mal.

Ce n'est pas un argument contre l'IA. C'est un argument pour une gouvernance de l'IA. Les organisations qui déploient des outils d'IA générative sans avoir d'abord défini qui décide quoi, quelles données peuvent être traitées par ces outils, comment les outputs sont validés, et qui est responsable des erreurs, ne se modernisent pas. Elles créent de nouvelles vulnérabilités en se croyant plus efficaces.

J'ai vu des projets qui auraient dû coûter 80 000 euros finir à plus de 3 millions d'euros après trois ans. Pas à cause de mauvaises technologies. À cause d'une organisation qui a cru que l'outil allait se substituer à la réflexion sur ses propres processus. On déploie rapidement, on itère, on "fail fast". Et on accumule une dette technique, organisationnelle et humaine qui finit par peser bien plus lourd que l'investissement initial.

Le paradoxe de la productivité numérique est bien documenté ; l'investissement dans un nouveau système s'accompagne presque toujours d'une baisse de productivité pendant la période d'adaptation. Si cette période est mal gérée, si les équipes ne sont pas formées, si les processus n'ont pas été pensés avant le déploiement, cette baisse ne se résout pas. Elle se prolonge, puis se cristallise en démotivation, en contournements, en shadow IT, en demande d'un nouveau système censé corriger l'ancien.

La bonne séquence est invariable. Comprendre d'abord ce qui se passe réellement dans l'organisation. Simplifier ensuite ce qui peut l'être, sans technologie. Optimiser les processus avant de les outiller. Et seulement alors, choisir et déployer les outils adaptés à ces processus clarifiés. Inverser cet ordre n'est pas une erreur de méthode. C'est une décision dont on paie les conséquences pendant des années.

Sur un audit de gouvernance des actifs IT conduit pour une organisation de taille intermédiaire, l'inventaire exhaustif des applications SaaS utilisées a révélé 140 outils actifs. Le budget SaaS officiel était de 1,2 million d'euros. Les dépenses réelles reconstituées à partir des flux réseau et des relevés de facturation atteignaient 2,8 millions. L'écart, 1,6 million d'euros par an, était entièrement constitué de souscriptions prises par les directions métier sans validation IT, par des équipes qui avaient trouvé plus simple de sortir leur carte bleue que de passer par un processus d'achat jugé trop lent.

Ce cas n'est pas exceptionnel. Il est représentatif de ce qu'on trouve dans la majorité des organisations qui n'ont pas mis en place une gouvernance formelle de leurs actifs SaaS. Huit outils de gestion de projet coexistaient sans coordination. Cinq solutions de stockage cloud différentes hébergeaient des données sans que personne n'ait évalué leur conformité RGPD. Des données clients se trouvaient sur des plateformes dont personne n'avait vérifié les conditions de sécurité ni la localisation des serveurs.

Après six mois de travail de consolidation, le portefeuille est passé de 140 à 52 applications. Les économies annuelles dégagées : 1,1 million d'euros. Toutes les applications critiques ont été évaluées sur la sécurité. La CMDB a été mise à jour et un processus de gestion des actifs a été institué. Ce n'est pas une performance extraordinaire. C'est ce que produit une démarche de gouvernance élémentaire, appliquée à un problème qui avait été ignoré pendant des années.

La réponse instinctive de beaucoup de DSI face au shadow IT est l'interdiction. Bloquer les souscriptions non autorisées, restreindre l'accès aux marketplaces d'applications, imposer des processus de validation centralisés. Cette réponse traite le symptôme sans toucher à la cause.

Le shadow IT prospère quand la DSI a perdu sa légitimité aux yeux des métiers. Quand les délais de traitement d'une demande d'outil se comptent en semaines ou en mois, les équipes trouvent leur propre solution en quarante-huit heures. Quand le catalogue de services proposé ne correspond pas aux besoins réels du terrain, les directions métier construisent leur propre catalogue. Ce n'est pas de la délinquance organisationnelle. C'est une réponse rationnelle à un service qui ne répond plus à la demande.

La bonne réponse n'est pas l'interdiction. C'est la reconquête de la légitimité par le service. Réduire les délais de validation, créer un catalogue d'outils pré-approuvés mis à jour régulièrement, instaurer un processus d'évaluation rapide pour les nouvelles demandes métier. Quand la DSI devient un facilitateur plutôt qu'un goulot d'étranglement, le shadow IT se tarit naturellement.

La prolifération SaaS non gouvernée crée trois catégories de risques qui s'accumulent silencieusement. Le risque financier d'abord ; des souscriptions jamais résiliées sur des outils abandonnés, des doublons fonctionnels payés plusieurs fois, des contrats renouvelés automatiquement sans évaluation. Dans l'audit mentionné plus haut, plusieurs outils n'avaient pas été utilisés depuis plus de six mois mais continuaient à générer des factures.

Le risque de sécurité ensuite. Chaque application SaaS représente un vecteur d'entrée potentiel, une surface d'authentification à sécuriser, un flux de données à surveiller. Des applications non évaluées traitent des données sensibles sur des infrastructures dont on ne connaît ni la localisation ni le niveau de sécurité. Des comptes créés pour des employés qui ont quitté l'organisation restent actifs, faute de processus de déprovisioning couvrant l'ensemble du périmètre SaaS.

Le risque de conformité enfin. Le RGPD impose que chaque traitement de données personnelles soit documenté, que les prestataires sous-traitants soient évalués, que les transferts hors UE soient encadrés. Une organisation qui ignore 60% de ses applications SaaS ne peut pas respecter ces obligations. Ce n'est pas une question d'intention ; c'est une impossibilité structurelle.

Tout le monde parle du phishing par email. Mais la plus grande surface de pénétration des attaquants dans les systèmes d'information se trouve dans les processus. La gestion du cycle de vie du personnel. Les procédures RH. Les enquêtes administratives. La gestion des identités et des accès. La gestion des actifs logiciels et matériels. Les processus d'achat. Sur ces seuls périmètres, la grande majorité des organisations auditées n'est pas à jour. Des single points of failure en pagaille, visibles pour qui sait regarder.

L'ingénierie sociale se sert de toutes ces faiblesses administratives et fonctionnelles. Il n'est pas nécessaire d'être un expert en hacking. À travers les processus défaillants, un attaquant peut obtenir des informations vitales pour mener une attaque foudroyante sans jamais toucher à un seul système informatique au sens technique du terme. L'OSINT, la collecte de renseignements en sources ouvertes, permet de cartographier une organisation, ses dirigeants, ses prestataires, ses processus internes, ses fournisseurs stratégiques, en quelques heures depuis des sources parfaitement légales et accessibles à tous.

Une fois cette cartographie établie, les vecteurs d'entrée se multiplient. Les accès physiques non sécurisés. Le shadow IT non inventorié. Les cloisonnements réseau défaillants. L'obsolescence des systèmes. La gouvernance des données absente. Les ACL mal configurées. Et en toute fin de cette chaîne, la gestion des mots de passe. Ce sont les fondations d'une compromission, pas ses outils avancés.

L'intelligence artificielle a changé l'échelle et la sophistication de l'ingénierie sociale. Ce qui nécessitait auparavant des heures de recherche manuelle et une capacité de personnalisation limitée peut maintenant être industrialisé. Un email de spear phishing parfaitement personnalisé, qui reprend le style d'écriture d'un dirigeant connu, fait référence à des événements récents de l'organisation, et imite une urgence crédible, peut être généré en quelques secondes et envoyé à des centaines de cibles simultanément.

Le vishing, les appels téléphoniques qui usurpent l'identité d'un interlocuteur de confiance, atteint un niveau de sophistication inédit avec les technologies de clonage vocal. L'arnaque au président, le business email compromise, a toujours reposé sur l'autorité et l'urgence comme leviers psychologiques. Avec l'IA, ces leviers sont amplifiés par une crédibilité technique que les destinataires n'ont pas les moyens de contester sans processus de vérification formels.

Ce qui ne change pas, c'est la nature humaine. La confiance, l'autorité et l'urgence sont des leviers psychologiques universels que les attaquants exploitent depuis que les organisations existent. L'IA les rend plus efficaces, plus rapides et plus économiques. Mais la réponse fondamentale n'est pas technique. C'est culturelle et organisationnelle.

La prise en compte sérieuse de l'ingénierie sociale dans la gouvernance des systèmes d'information implique de regarder bien au-delà des périmètres techniques habituels. Les processus RH d'abord ; chaque entrée et surtout chaque sortie de personnel est un moment de risque. Un accès non révoqué à un ancien employé, une habilitation héritée d'un poste précédent jamais nettoyée, un badge physique non récupéré ; autant de vecteurs d'entrée qui ne nécessitent aucune technique de hacking.

Les processus d'achat et de gestion des prestataires ensuite. Un fournisseur compromis qui a un accès légitime à vos systèmes est infiniment plus difficile à détecter qu'un attaquant externe qui force une entrée. Les attaques sur la chaîne d'approvisionnement, illustrées ces dernières années par des incidents majeurs dans des entreprises technologiques mondiales, reposent précisément sur cette logique ; pénétrer un maillon faible de la chaîne pour atteindre les cibles qui, seules, auraient été bien protégées.

La sensibilisation des équipes enfin, mais pas sous forme de formations annuelles d'une heure que personne ne retient. Des simulations régulières de phishing dont l'objectif n'est pas de sanctionner ceux qui cliquent mais de mesurer l'évolution du niveau de vigilance collectif. Un environnement où signaler une tentative suspecte est valorisé et non source de honte. Et des procédures de vérification formelles pour les demandes inhabituelles, en particulier celles qui invoquent l'urgence ou l'autorité d'un dirigeant, quelles que soient les apparences de légitimité.

L'audit avait été commandité par la direction générale d'une administration centrale. L'objectif officiel portait sur la gouvernance des systèmes d'information ; maturité COBIT, état des processus ITIL, conformité ISO, cartographie des risques. Un périmètre classique. Ce que la direction souhaitait également, sans en faire un objectif formalisé, c'est qu'on "regarde aussi comment les choses se passent concrètement sur le terrain". Cette formulation prudente donnait latitude pour aller au-delà des questionnaires et des entretiens. J'en ai pris acte.

Ce qui suit est le récit des observations réalisées lors de cette composante non annoncée aux équipes opérationnelles. Les faits sont exacts. Les détails qui permettraient d'identifier l'organisation ont été volontairement omis. L'objectif n'est pas l'anecdote ; c'est de montrer ce que révèle systématiquement ce type d'exercice dans les environnements qui n'ont jamais été testés.

Le bâtiment disposait d'un système de contrôle d'accès par badge à l'entrée principale et aux accès secondaires. En théorie. En pratique, la porte d'entrée principale était maintenue ouverte une bonne partie de la matinée pour faciliter les allées et venues lors des réunions du matin. Ce n'était pas une défaillance technique. C'était une habitude organisationnelle, tolérée depuis si longtemps qu'elle était devenue invisible.

Je suis entré sans badge, sans être interpellé, en portant simplement une mallette et en adoptant la démarche de quelqu'un qui sait où il va. La règle non écrite qui régit la plupart des espaces de travail est simple ; quelqu'un qui a l'air d'être à sa place est à sa place. Personne ne questionne celui qui marche avec assurance. Personne n'arrête celui qui tient une porte pour quelqu'un d'autre, ou qui suit naturellement un groupe qui vient de s'authentifier.

Ce que cette observation révèle n'est pas un déficit d'équipement. L'administration avait investi dans des systèmes de contrôle d'accès conformes aux exigences réglementaires. Ce qu'elle n'avait pas fait, c'est former ses agents à appliquer les procédures de contrôle qui donnent leur sens à ces équipements. Un badge lecteur sans la culture de son usage systématique est un meuble.

Une fois dans les espaces de travail, la phase suivante consistait à observer les interactions et à engager des conversations. L'ingénierie sociale repose sur un catalogue de leviers psychologiques bien documentés ; l'autorité, l'urgence, la réciprocité, la sympathie, la preuve sociale. Dans un environnement administratif, la sympathie est souvent le levier le plus efficace parce qu'il est le moins défensif. On se méfie de quelqu'un qui invoque l'autorité ou l'urgence. On ne se méfie pas de quelqu'un d'agréable avec qui on engage une conversation naturelle.

En me présentant simplement comme un consultant missionné par la direction, sans fausses déclarations sur mon identité ou mes fonctions, j'ai engagé des conversations avec plusieurs agents sur les difficultés qu'ils rencontraient avec les outils informatiques. Des difficultés réelles, visibles, frustrantes pour eux. En exprimant de l'intérêt sincère pour leurs problèmes, en posant des questions techniques pertinentes qui montraient que je comprenais leur environnement, plusieurs agents ont spontanément proposé de me "montrer" comment les choses fonctionnaient. Depuis leur poste de travail. Sans déverrouillage supplémentaire. Avec leurs propres accès.

Un agent a ainsi ouvert, sans que je le lui demande, l'interface d'administration d'un système critique pour m'expliquer un problème récurrent qu'il rencontrait. Il voulait montrer qu'il maîtrisait son outil et que le problème venait d'ailleurs. J'avais accès visuel à des données de configuration sensibles, à des comptes d'administration actifs, et à l'architecture d'un système que j'aurais mis plusieurs jours à cartographier par des moyens conventionnels. La conversation avait duré moins de quinze minutes.

Ce que cet agent a fait n'est pas stupide. C'est humain. Il aidait quelqu'un qui semblait légitime, qui s'intéressait à ses problèmes, et qui allait potentiellement les résoudre. Le problème n'est pas son comportement. C'est l'absence d'un cadre qui lui aurait donné les outils pour distinguer cette situation d'une situation à risque.

La salle serveur d'une administration centrale est, en principe, un espace à accès restreint. En pratique, les règles qui définissent cet accès restreint peuvent être contournées par des voies qui n'ont rien de technique. En exprimant une demande directe auprès d'un responsable technique, en expliquant que je devais "vérifier quelque chose sur l'infrastructure dans le cadre de l'audit", et en maintenant un registre professionnel et compétent dans la formulation des questions techniques qui ont précédé cette demande, j'ai obtenu un accès accompagné à la salle serveur.

Ce qui était visible dans cet espace dépassait largement ce qu'un rapport d'audit technique aurait pu documenter. Des équipements non inventoriés dans la CMDB officielle, identifiables à l'étiquetage manuel sur les baies. Des câblages réseaux non documentés. Des terminaux de maintenance connectés en permanence à des équipements critiques. Et, sur un écran visible depuis l'entrée de la salle, une interface de supervision connectée avec des identifiants en clair dans la barre d'adresse du navigateur.

Je n'ai rien touché. Je n'ai rien noté en présence du responsable technique. Mais j'avais vu assez pour comprendre l'étendue réelle de la surface d'attaque. Ce que j'avais trouvé en deux heures de présence physique dans cette organisation aurait nécessité des semaines d'attaque technique pour être obtenu par voie numérique.

La restitution de ces observations à la direction générale a produit un silence inhabituellement long pour ce type de réunion. Non par surprise sur les faits eux-mêmes, dont certains étaient vaguement pressentis, mais par la brutalité de les voir formulés avec précision, chronologie et preuves d'observation à l'appui. Le responsable de la sécurité des systèmes d'information, présent, a posé une seule question ; combien de temps avait duré l'ensemble de l'exercice. Deux heures, lui ai-je répondu. Il n'a pas ajouté de commentaire.

Ce qui a suivi dans le rapport final n'était pas un catalogue de sanctions ou de reproches. C'était une analyse de causes ; pourquoi les procédures existantes n'étaient pas appliquées, pourquoi les agents n'avaient pas les réflexes qui auraient rendu ces observations impossibles, pourquoi l'organisation avait investi dans des équipements de contrôle sans investir dans la culture qui leur donne leur sens. Et un plan de remédiation sur trois niveaux ; procédures actualisées et simplifiées, formation continue sur les vecteurs d'ingénierie sociale, exercices réguliers non annoncés pour maintenir le niveau de vigilance dans la durée.

Ce que cette expérience m'a confirmé une fois de plus ; le niveau de sécurité réel d'une organisation ne se mesure pas à ses équipements. Il se mesure à ce qui se passe quand personne ne regarde, quand la procédure est perçue comme une gêne plutôt qu'une protection, et quand quelqu'un de sympathique s'intéresse sincèrement à vos problèmes informatiques.

L'administration publique n'a pas le monopole de ces vulnérabilités. Une mission dans le secteur du retail m'a fourni, en l'espace d'une matinée, une démonstration peut-être encore plus frappante de la façon dont la confiance et la bonne volonté peuvent constituer les meilleurs passe-partout qui soient.

Le PDG m'avait missionné pour épauler sa DSI dans l'amélioration de la gouvernance des systèmes d'information. Dès la première réunion de travail, je demande à la responsable informatique si elle peut me donner accès à internet pour travailler. Sans hésitation, elle ouvre la connexion WiFi de l'entreprise sur mon ordinateur portable et saisit elle-même les identifiants de connexion. Ce faisant, elle ignore deux réalités simultanées. La première ; que je regarde. La seconde ; que n'importe quel ordinateur peut dissimuler un enregistreur de frappe, un keylogger, qui capture tout ce qui est tapé sur un clavier sans aucune manifestation visible. Le mot de passe saisi était court, dépourvu de toute complexité, et le SSID du réseau WiFi d'entreprise était visible par quiconque cherchait une connexion dans le périmètre du bâtiment. N'importe quel attaquant modérément compétent aurait pu casser cette protection en quelques minutes. Moi, en quelques secondes, j'avais tout.

La séquence ne s'est pas arrêtée là. Pour me présenter les systèmes de l'organisation, la responsable informatique s'est connectée sur l'ERP de l'entreprise depuis mon poste de travail, me faisant une démonstration des modules achats, de la gestion des actifs, de la logistique. Je voyais les données, les structures, les identifiants de connexion, les niveaux d'accès. Elle montrait son environnement à quelqu'un qu'elle venait de rencontrer, sur un matériel qu'elle ne contrôlait pas, sans que cela lui pose la moindre question.

En sortant de l'entreprise ce jour-là, je me suis garé sur le parking. Avec une antenne amplificatrice, j'ai capté le réseau WiFi de l'organisation depuis l'extérieur du bâtiment. Je m'y suis connecté sans difficulté. Je suis resté connecté pendant une heure entière. Personne ne l'a détecté. Aucune alerte n'a été déclenchée. Aucune déconnexion forcée. Un attaquant avec les mêmes moyens et de mauvaises intentions aurait disposé d'une heure d'accès non surveillé à l'infrastructure réseau de l'entreprise, depuis le parking.

L'ensemble de ces observations a figuré dans le rapport d'évaluation à 360 degrés remis au PDG. Elles n'ont pas été présentées comme des fautes professionnelles de la responsable informatique. Elles ont été présentées pour ce qu'elles sont ; la conséquence prévisible d'une organisation qui n'a jamais formalisé ses procédures de sécurité opérationnelle, qui n'a jamais formé ses équipes aux réflexes élémentaires, et qui croit que la sécurité se résume aux outils qu'elle a achetés. Cette responsable informatique était compétente dans son domaine technique. Simplement, personne ne lui avait jamais dit que taper un mot de passe sur l'ordinateur d'un inconnu est l'un des gestes les plus risqués qu'un responsable IT puisse faire.

Les organisations IT ont une tendance naturelle et compréhensible à s'organiser par domaine d'expertise. L'infrastructure d'un côté, la sécurité de l'autre, les applications métier ailleurs, l'environnement de travail numérique encore séparément. Cette logique répond à une exigence réelle ; la profondeur technique nécessite de la spécialisation. Un ingénieur réseau, un expert sécurité, un développeur applicatif ne font pas le même travail et ne doivent pas être interchangeables.

Mais cette organisation par silos techniques produit, presque mécaniquement, des pathologies organisationnelles que j'ai retrouvées dans chaque grande structure auditée. Les processus de gestion des incidents ne sont pas unifiés ; chaque silo gère ses propres incidents avec ses propres niveaux de priorité, ses propres escalades, et ses propres métriques. Le résultat concret ; un incident qui traverse deux silos, un problème réseau qui impacte une application métier par exemple, peut passer des heures dans un espace inter-silo sans propriétaire. Chaque équipe attend que l'autre confirme sa responsabilité avant d'agir.

La qualité souffre du même syndrome. Quand chaque silo développe ses propres indicateurs, ses propres critères d'acceptation, ses propres processus d'amélioration continue, il n'existe pas de vision consolidée de la qualité de service perçue par les utilisateurs finaux. On mesure des composants techniques, pas des services. Et le client, lui, ne vit pas des composants ; il vit des services.

Le pilotage de projet subit la même fragmentation. Quand chaque département technique lance ses propres projets selon ses propres priorités, des redondances apparaissent. Deux silos achètent des outils qui font la même chose. Deux équipes développent des solutions qui auraient pu être mutualisées. Des projets qui nécessitent la contribution de plusieurs silos n'avancent qu'au rythme du silo le moins disponible, sans arbitre transverse pour débloquer les conflits de ressources.

La réponse à ces pathologies n'est pas de supprimer les silos techniques. C'est de leur superposer une couche transverse qui gère ce que les silos, par définition, ne peuvent pas gérer seuls ; tout ce qui traverse plusieurs domaines, tout ce qui s'adresse aux utilisateurs finaux indépendamment du composant technique concerné, et tout ce qui relève de la cohérence d'ensemble.

C'est le modèle des Centres de Services Partagés, mis au service d'une gouvernance des systèmes d'information efficace et harmonisée. Ce modèle, éprouvé dans les grandes ESN internationales et les groupes industriels qui opèrent des SI complexes, repose sur une distinction fondamentale ; les silos techniques restent maîtres de leur expertise verticale, pendant que des fonctions transverses opérationnelles assurent l'horizontalité sans laquelle la cohérence est impossible.

Ces fonctions transverses sont au nombre de neuf ; delivery, capacity management, qualité, gestion des configurations et des actifs IT, sécurité, achats IT, support (monitoring, N1, N2), direction de projet, et moyens généraux. Leur nombre peut varier selon la taille et la maturité de l'organisation, certaines pouvant être mutualisées dans les structures plus légères, mais le principe est invariable ; chacune perd sa raison d'être si elle est enfermée dans un seul silo. Elles tirent leur valeur précisément du fait qu'elles surplombent tous les silos et parlent le même langage à tous.

Sur la question des silos techniques eux-mêmes, il n'existe pas de modèle unique. Leur nombre et leur granularité dépendent directement de la taille de l'organisation, de la criticité de son SI, et de la nature de son activité. Une structure de taille intermédiaire peut regrouper toute l'infrastructure dans un seul silo. Une grande direction du numérique d'un ministère, une ESN multi-clients, ou un groupe industriel opérant des environnements critiques décomposera ce même périmètre en spécialités distinctes et irréductibles ; des équipes mainframe séparées des équipes Unix, Linux et Windows, qui elles-mêmes ne travaillent pas avec les équipes virtualisation ni avec les équipes stockage et sauvegarde. À cela s'ajoutent des pôles réseaux et télécommunications, des pôles bases de données spécialisés par technologie, des équipes applicatives métier par domaine fonctionnel, des équipes d'industrialisation de l'environnement de travail numérique, et des équipes dédiées à l'industrialisation des outils d'exploitation. Ce que le modèle transverse garantit, c'est que quelle que soit cette granularité, ces fonctions horizontales continuent à fonctionner de façon cohérente au-dessus de tous ces silos. Ce n'est pas la taille du SI qui rend le modèle transverse nécessaire. C'est la complexité des interfaces entre silos. Et plus les spécialisations sont fines, plus ces interfaces sont nombreuses, plus la couche transverse est indispensable.

La gestion des configurations et des actifs IT est une fonction transverse souvent sous-estimée, et pourtant fondatrice de presque toutes les autres. Sans elle, il est impossible de piloter correctement les incidents, les changements, les capacités ou la sécurité. La CMDB consolidée et l'ITAM, la gestion des actifs logiciels et matériels, constituent le référentiel commun auquel toutes les fonctions transverses se raccordent. La gestion des configurations interagit avec le support pour qualifier les actifs impactés lors d'un incident, avec les achats pour réconcilier les contrats et les licences avec l'inventaire réel, avec le capacity management pour anticiper les renouvellements et les obsolescences, avec la sécurité pour identifier les composants vulnérables, et avec les change managers lors du CAB pour évaluer l'impact d'un changement sur l'ensemble des éléments de configuration concernés. Une CMDB mal tenue ou partielle ne rend pas seulement le pilotage des incidents approximatif ; elle rend toute la gouvernance des SI aveugle à une part de sa propre réalité.

Le support transverse est la première brique, et souvent la plus visible pour les utilisateurs. Il s'organise en trois niveaux complémentaires qui constituent ensemble un dispositif cohérent de détection, de qualification et de résolution. Au sommet, une équipe dédiée au monitoring assure la surveillance proactive et en temps réel de l'ensemble du périmètre SI : supervision des infrastructures, des applications, des flux réseau et des indicateurs de performance. C'est elle qui détecte les incidents avant que les utilisateurs les signalent, qui anticipe les seuils de saturation, et qui alerte les équipes concernées sans attendre que la dégradation devienne visible. Le support N1, le helpdesk, constitue le single point of contact pour l'ensemble des utilisateurs finaux quelle que soit la nature de leur problème. L'utilisateur n'a pas à savoir si son problème relève du réseau, de l'application ou de son poste de travail. Il contacte un point unique, qui qualifie, oriente, et assure le suivi jusqu'à la résolution. Ce que le N1 ne peut pas résoudre en première intention est escaladé vers le support N2, dont le rôle est la prise en charge des incidents plus complexes nécessitant une expertise technique plus poussée, sans pour autant appartenir à un silo ; le N2 intervient sur l'ensemble du périmètre, en interface directe avec les équipes des silos techniques pour les cas qui dépassent son propre périmètre d'intervention. L'efficacité de ce dispositif à trois niveaux repose sur une condition fondamentale ; chacun doit avoir une visibilité sur l'ensemble du périmètre SI. Un support enfermé dans un silo technique n'est pas un support transverse. C'est un service desk partiel.

Le delivery transverse couvre la gestion opérationnelle de la délivrance des services selon les processus ITIL : gestion des incidents, gestion des problèmes, gestion des changements, et coordination des projets en délivrance. Sa valeur réside dans l'unification de ces processus à l'échelle de l'ensemble de l'organisation, pas silo par silo. C'est lui qui détient la vision consolidée des niveaux de service, qui pilote les SLA avec les métiers, et qui remonte au management une image fidèle de la qualité de service réelle, pas la somme des visions partielles de chaque silo. Sans delivery transverse, le directeur des SI ne peut pas répondre à la question "quel est notre niveau de service aujourd'hui ?" sans compiler manuellement des tableaux de bord incompatibles.

À l'intérieur de cette fonction delivery, l'organisation des rôles suit elle aussi une logique de taille critique. Le Service Delivery Manager est la figure centrale ; c'est lui qui porte la relation avec le client ou la direction métier, qui consolide la vision de la performance sur son périmètre, et auquel rendent compte les responsables de processus. Car le delivery n'est pas un rôle unique. Il réunit des Incident Managers, responsables de la restauration rapide du service et de l'orchestration des équipes techniques lors des crises ; des Problem Managers, chargés de l'analyse des causes racines, de la capitalisation sur les incidents récurrents, et de la réduction durable du volume d'incidents ; et des Change Managers, garants de la maîtrise des changements, de l'évaluation des risques associés et de la coordination du CAB. Chacun rend compte au SDM qui, lui, rend compte au client. Dans les structures de taille intermédiaire, ces rôles peuvent être mutualisés ; un Incident Manager gère plusieurs clients simultanément, un Problem Manager couvre l'ensemble du périmètre, un Change Manager préside le CAB pour tous les comptes. Dans les grandes structures ou sur les comptes stratégiques à fort volume, ces rôles deviennent dédiés ; un SDM exclusivement assigné à un client, un Incident Manager spécifique à ce compte, un Problem Manager qui connaît l'historique d'incidents de ce seul périmètre. C'est ce niveau de granularité qui permet une relation de service véritablement personnalisée, une anticipation des problèmes propres à chaque environnement, et une restitution au client d'une image fidèle de son propre niveau de service.

Le capacity management est une fonction facilitatrice au sens plein du terme. Son rôle couvre deux dimensions complémentaires que l'on a tendance à séparer alors qu'elles sont indissociables. La capacité technique d'abord ; dimensionnement des infrastructures, gestion des licences, anticipation des seuils de saturation, planification des renouvellements matériels. Et la capacité humaine ensuite ; planification des ressources sur les projets, sur le run, sur les formations, en coordination avec les RH, les achats, les directeurs de projet, les service managers de chaque pôle et les SDM. C'est le capacity manager qui alerte lorsqu'un silo est en surcharge, qui identifie les conflits de ressources entre un projet et les engagements de run, qui valide avec l'avant-vente la faisabilité d'un engagement commercial avant qu'il soit signé. Il participe aux CAB aux côtés des change managers pour évaluer l'impact des changements sur les capacités disponibles. Dans les grandes organisations, son rôle d'alerte sur les différents niveaux de gouvernance en fait un acteur central de la résilience opérationnelle.

La qualité transverse est peut-être la fonction dont l'importance est la plus systématiquement sous-estimée. Dans la plupart des organisations que j'audite, la qualité est soit absente, soit enfermée dans un département qui produit des rapports que personne ne lit, soit éparpillée dans chaque silo sous des formes incompatibles. Or la qualité transverse, c'est ce qui garantit que l'amélioration continue est réelle et pas seulement déclarée. C'est elle qui consolide les indicateurs de performance, qui pilote les audits internes, qui suit les plans d'amélioration issus des incidents et des problèmes. Lors de mon audit d'une grande direction nationale du numérique, j'ai proposé que la qualité soit extraite des silos techniques et placée en fonction transverse, avec une autorité de pilotage sur l'ensemble du périmètre. Ce n'était pas une décision évidente dans une culture où chaque département gardait jalousement sa propre démarche qualité. C'était pourtant la condition pour que les référentiels adoptés, COBIT, ITIL, ISO, produisent leurs effets au niveau de l'organisation et non seulement au niveau de chaque composant.

La sécurité transverse est peut-être la plus mal placée de toutes les fonctions dans les organisations silotées. On la trouve le plus souvent rattachée à l'infrastructure ou à l'architecture, ce qui la cantonne à une dimension technique et lui retire l'autorité nécessaire pour imposer des exigences à l'ensemble des entités. Or la sécurité des systèmes d'information est par nature transverse ; une politique de gestion des accès ne concerne pas seulement l'infrastructure, elle concerne les applications métier, les environnements de travail numérique, les projets en cours, les processus RH et achats. Et sous NIS2, son positionnement organisationnel est désormais une question réglementaire ; l'article 20 impose que les organes de direction approuvent et supervisent les mesures de gestion des risques de cybersécurité, ce qui suppose un RSSI disposant d'un lien de reporting direct vers la direction générale et le conseil d'administration, indépendant de la DSI pour éviter tout conflit d'intérêts structurel entre le contrôleur et le contrôlé.

La direction des achats IT est une fonction transverse dont la valeur tient précisément à sa position surplombante. Quand les achats sont décentralisés dans chaque silo, chaque entité négocie ses propres contrats, renouvelle ses propres licences, sollicite ses propres prestataires. Les conséquences sont systématiques ; des doublons contractuels sur les mêmes périmètres, une atomisation des leviers de négociation qui empêche d'obtenir les conditions qu'une vision consolidée permettrait, et une absence de vision du TCO global. La direction des achats transverse travaille en lien direct avec la gestion des configurations et des actifs pour réconcilier les contrats avec l'inventaire réel, avec le capacity management pour anticiper les besoins de renouvellement, et avec le juridique pour intégrer dans les contrats les exigences de conformité réglementaire, notamment les clauses d'audit, de réversibilité et d'évaluation des fournisseurs critiques imposées par NIS2.

La direction de projet transverse résout le problème des redondances et des parallélismes que toute organisation silotée produit inévitablement. Deux silos qui ne se parlent pas peuvent acheter les mêmes outils, lancer les mêmes chantiers, solliciter les mêmes prestataires. Une direction de projet transverse maintient une vision unifiée du portefeuille de projets, arbitre les conflits de ressources, identifie les redondances avant qu'elles soient engagées, et garantit que les projets qui nécessitent la contribution de plusieurs silos disposent d'un pilotage qui surplombe ces silos. Sans elle, le chef de projet d'un silo qui a besoin d'une contribution d'un autre silo n'a aucun levier d'action quand l'autre silo priorise autrement. La direction de projet transverse est ce levier.

Les moyens généraux sont la fonction transverse la plus silencieuse et pourtant omniprésente. Ils couvrent tout ce qui conditionne physiquement le fonctionnement des silos techniques sans appartenir à aucun d'eux ; les locaux, les salles serveurs et leurs contraintes d'alimentation électrique et de climatisation, le câblage structuré, les accès physiques et leur sécurisation, les contrats de facility management. Ils interagissent avec la sécurité pour la protection physique des infrastructures, avec les achats pour les contrats de maintenance des installations, avec la gestion des configurations pour tenir à jour les éléments d'infrastructure physique, et avec la direction de projet pour les travaux d'aménagement liés aux évolutions du SI.

Au-dessus de toutes ces fonctions transverses opérationnelles, deux instances de gouvernance complètent le modèle. La DSI n'est pas un silo parmi d'autres ; elle est la direction qui pilote stratégiquement l'ensemble du dispositif, arbitre les priorités, alloue les ressources entre silos et fonctions transverses, et assure l'alignement permanent du SI sur les objectifs de l'organisation. C'est elle qui traduit les décisions de la direction générale en orientations opérationnelles, et qui remonte au COMEX une vision consolidée de la performance, des risques et des investissements SI. La direction générale enfin est partie prenante incontournable de la gouvernance des SI, non dans le détail des opérations, mais dans la définition des objectifs stratégiques dont dépend la cascade COBIT, dans la validation du niveau de risque acceptable, et dans l'arbitrage des investissements majeurs. Une gouvernance des SI sans engagement de la direction générale reste une gouvernance partielle ; elle peut optimiser les opérations sans jamais pouvoir aligner le SI sur la trajectoire de l'organisation.

La direction nationale auditée était organisée autour de sept entités informatiques spécialisées, chacune maîtresse de son domaine technique. L'infrastructure et les réseaux. L'architecture et la sécurité. L'environnement de travail numérique. Le développement applicatif et les projets métier. La qualité. Les achats IT. Et une direction du numérique chargée de la supervision stratégique de l'ensemble.

Ce que l'audit a mis en évidence ; chacune de ces entités fonctionnait selon sa propre logique, avec ses propres processus, ses propres indicateurs, et ses propres interfaces avec les métiers. La qualité était dans un département qui produisait des rapports mais n'avait pas d'autorité transverse pour imposer des améliorations dans les autres entités. Le support était réparti entre plusieurs entités selon la nature des tickets, sans vision consolidée des incidents qui traversaient plusieurs périmètres. Les projets étaient pilotés entité par entité, avec des cas identifiés de redondances fonctionnelles entre des projets conduits en parallèle dans des entités différentes sans coordination.

Les recommandations formulées visaient à conserver intacte la profondeur d'expertise de chaque entité technique, tout en créant plusieurs fonctions transverses opérationnelles ; un centre de support unifié comme premier point de contact pour l'ensemble des utilisateurs, une fonction delivery transverse portant les processus ITIL à l'échelle de l'organisation, une fonction qualité avec autorité transverse sur l'ensemble du périmètre, une direction de projet transverse arbitrant le portefeuille et les ressources, une gestion des configurations et des actifs IT consolidée, et une sécurité positionnée en transverse avec un lien de reporting direct vers la direction générale. La gouvernance stratégique de l'ensemble s'appuyait sur les cinq objectifs de gouvernance COBIT, garantissant l'établissement du cadre, la délivrance de valeur, l'optimisation des risques, l'optimisation des ressources, et l'engagement des parties prenantes.

Ce modèle n'est pas une invention. C'est la formalisation de ce que les grandes ESN et groupes industriels qui gèrent des SI complexes ont appris, souvent au prix d'échecs coûteux, que les silos seuls ne peuvent pas assurer. Ces deux environnements m'ont permis de voir ce modèle fonctionner à grande échelle, dans des contextes où la rigueur opérationnelle n'était pas un objectif mais une condition de survie commerciale. Le transposer dans des organisations publiques qui n'ont jamais connu ce modèle demande un travail pédagogique important. Mais les bénéfices, en cohérence de service, en réduction des doublons, en qualité perçue par les métiers, et en capacité de transformation, justifient largement cet investissement.

Les mesures de maturité des systèmes d'information conduites par les grands cabinets d'audit et de conseil convergent sur un constat stable depuis plusieurs années. Les organisations, indépendamment de leur taille et de leur secteur, présentent des scores COBIT 2019 moyens inférieurs à 2 sur 5. Ce niveau correspond à des processus planifiés mais non standardisés, des pratiques dépendantes des individus plutôt que des procédures, et une absence de boucle d'amélioration continue.

L'audit de gouvernance informatique conduit sur un ministère français et ses vingt-quatre directions régionales illustre ce diagnostic à grande échelle. Sur les cinq domaines COBIT, deux obtiennent des scores inférieurs à 1,5 ; EDM01 (cadre de gouvernance) et BAI09 (gestion des actifs). Les directions régionales appliquent des pratiques différentes sur des périmètres identiques. Aucune consolidation nationale fiable n'est possible. Les décisions d'investissement reposent sur des données incomplètes.

Trois forces reconfigurent simultanément le paysage applicatif d'entreprise. L'intelligence artificielle générative a cessé d'être un différenciateur commercial pour devenir une condition d'accès au marché. SAP Joule, Salesforce Agentforce, Workday Illuminate, ServiceNow Now Assist ; chaque éditeur majeur embarque désormais des capacités d'IA dans son coeur fonctionnel. L'architecture dominante en entreprise est le RAG, Retrieval-Augmented Generation, qui connecte un modèle de langage aux données structurées de l'ERP, de la CMDB ou du SIRH. Les organisations qui maîtrisent ces architectures créent un avantage compétitif mesurable sur celles qui achètent une fonctionnalité IA comme option de module.

Sur la souveraineté numérique, la situation est précise. 87% du cloud public mondial est hébergé par trois éditeurs américains soumis au CLOUD Act de 2018. La réponse opérationnelle consiste à cartographier les données par niveau de sensibilité, à sélectionner les hébergeurs en fonction des exigences juridictionnelles réelles, et à contractualiser les droits de portabilité et de sortie. Les labels SecNumCloud de l'ANSSI et HDS encadrent cette démarche pour les organisations françaises. Sur le plan réglementaire, NIS2, DORA et l'AI Act forment un corpus cohérent qui transforme des exigences de gouvernance SI autrefois volontaires en obligations légales assorties de sanctions significatives.

Nassim Nicholas Taleb a formalisé le concept de Cygne Noir ; un événement rare, imprévisible, d'impact massif. La méthodologie développée par I2S-Consultants repose sur son miroir ; le Cygne Blanc. Le Cygne Blanc est un risque visible, prévisible, pour lequel les moyens de prévention sont connus, et que les organisations choisissent néanmoins de ne pas traiter. Le déploiement d'un ERP sans cartographie BPM préalable est un Cygne Blanc. La mise en production d'une CMDB sans processus de mise à jour embarqués dans les workflows ITSM est un Cygne Blanc. Le lancement d'un programme de transformation sans sponsor exécutif formellement désigné est un Cygne Blanc.

L'indice Phi développé par I2S-Consultants mesure l'antifragilité des systèmes d'information sur quatre composantes ; la fiabilité structurelle des processus, la résilience face aux variations de charge, la capacité de récupération après incident, et la faculté d'adaptation aux évolutions réglementaires et technologiques. Les organisations qui obtiennent les scores Phi les plus élevés partagent trois pratiques ; elles cartographient leurs risques SI régulièrement, elles maintiennent une CMDB fiable à plus de 85% de cohérence avec le parc réel, et elles font auditer leur gouvernance par des tiers au moins tous les deux ans.

Le projet SAP de Lidl reste la référence absolue en matière de customisation excessive. Entre 2011 et 2018, le groupe a investi 500 M€ et mobilisé jusqu'à 800 consultants simultanément pour tenter d'adapter SAP Retail à ses processus de valorisation des stocks au prix d'achat historique. SAP impose le prix moyen pondéré comme méthode de référence. Plutôt que d'aligner ses processus comptables sur le standard de l'éditeur, Lidl a tenté l'inverse. Les personnalisations se sont accumulées jusqu'au point de non-retour. Le projet a été abandonné après sept ans sans mise en production.

Hershey illustre un mécanisme différent ; la compression irréaliste des délais. En 1996, la direction impose un déploiement simultané de SAP R/3, Manugistics et Siebel en trente mois, contre quarante-huit évalués par les équipes projet. La mise en production a lieu en juillet 1999, juste avant Halloween, période critique pour un fabricant de confiseries. La base de données de commandes est corrompue, la planification des livraisons impossible, les stocks introuvables. Les pertes s'élèvent à 100 M$ sur un seul trimestre. Le NHS England produit un troisième modèle d'échec ; le déploiement sans gouvernance centrale. ServiceNow a été déployé dans plusieurs NHS Trusts sans pilotage unifié. Résultat ; 47 instances séparées et incompatibles, aucune CMDB consolidée, 200 M£ en licences redondantes. Chaque Trust avait configuré ses propres processus, rendant toute consolidation impossible sans refonte complète.

Nestlé USA a lancé en 1997 un programme SAP de 200 M$ pour unifier neuf unités d'affaires indépendantes. Après un démarrage difficile marqué par une résistance massive des équipes et des problèmes de qualité des données maîtres, la direction a nommé une nouvelle CIO avec un mandat clair ; standardiser les processus avant de déployer la technologie. Cette reséquence a produit 325 M$ d'économies sur les achats seuls dans les trois années suivant la mise en production. FedEx a migré l'ensemble de ses fonctions Finance et Supply Chain vers Oracle Cloud ERP entre 2019 et 2023, en parallèle d'Oracle HCM pour 550 000 collaborateurs. Le projet a permis d'automatiser plusieurs centaines de processus financiers et de réduire d'une journée complète le délai de clôture mensuelle. Toyota, avec son déploiement SAP sur trente ans de convergence progressive, a construit un standard mondial de gestion de la production en s'appuyant sur ses propres standards de processus plutôt qu'en les sacrifiant aux paramétrages de l'éditeur.

L'analyse croisée de Panorama Consulting, Deloitte et Gartner sur plusieurs centaines de projets ERP et ITSM produit un ensemble stable de facteurs de succès. En premier lieu, la présence d'un sponsor exécutif visible et actif au niveau COMEX, avec un mandat opérationnel réel. En second lieu, la clarté et la stabilité des objectifs ; les projets qui maintiennent un périmètre fonctionnel stable entre le lancement et la mise en production réduisent de 40% leur risque de dépassement budgétaire. En troisième lieu, la qualité des données maîtres traitée comme un workstream autonome, budgété et gouverné séparément du déploiement fonctionnel. En quatrième lieu, le change management positionné comme livrable de premier rang, jamais comme variable d'ajustement budgétaire. En cinquième lieu, le choix d'un intégrateur dont les références sectorielles correspondent précisément au contexte client. En sixième lieu, un plan de retour arrière défini avant le démarrage. En septième lieu, un budget de support post go-live représentant au minimum 15 à 25% du coût d'implémentation, maintenu pendant au moins dix-huit mois.

La répartition standard d'un budget ERP, telle qu'établie par ERPResearch en 2026, suit une structure relativement stable quel que soit l'éditeur. Le conseil et l'intégration SI absorbent entre 40 et 50% du budget total. Les licences ou abonnements représentent 20 à 30%. La migration de données, systématiquement sous-estimée, mobilise 10 à 15% des ressources et génère fréquemment des retards de quatre à six mois quand elle n'est pas traitée comme un workstream autonome. La formation et le change management pèsent 10 à 20% ; ces postes sont les premiers sacrifiés lors des révisions budgétaires en cours de projet, avec des conséquences directes sur le taux d'adoption post go-live. Le support post go-live représente entre 15 et 25% du coût d'implémentation et doit être budgété sur un minimum de dix-huit mois.

Sur les coûts de licence, les benchmarks 2026 permettent d'établir des ordres de grandeur fiables. SAP S/4HANA Public Cloud via GROW with SAP se positionne entre 180 et 250 dollars par utilisateur par mois pour les ETI de 200 à 2 000 personnes, avec un coût d'implémentation totale de 800 K$ à 3 M$ et un TCO sur cinq ans de 2 à 8 M$. Microsoft Dynamics 365 Finance and Operations se situe entre 180 et 210 dollars par utilisateur par mois pour les grandes entreprises, avec une implémentation de 500 K$ à 2,5 M$ et un TCO sur cinq ans de 1,5 à 7 M$. Siveco Coswin en mode SaaS GMAO se positionne entre 80 et 150 euros par utilisateur par mois pour les ETI, avec une implémentation de 150 à 800 K€.

La customisation excessive est le premier facteur d'explosion budgétaire. Deloitte établit qu'elle ajoute entre 50 et 200% au coût de base selon le niveau de personnalisation accepté. La règle opérationnelle appliquée sur le terrain est simple ; chaque développement spécifique doit être justifié par un gain métier mesurable supérieur à son coût de maintenance sur cinq ans. La qualité insuffisante des données maîtres génère systématiquement quatre à six mois de retard supplémentaire. Le nettoyage des référentiels articles, fournisseurs, clients et actifs doit démarrer au minimum six mois avant le début du déploiement technique. Le scope creep, soit l'élargissement progressif du périmètre fonctionnel en cours de projet, est responsable d'un dépassement moyen de dix-huit mois sur les grands programmes. Un comité de contrôle du périmètre avec un processus formel de gestion des demandes de changement est la réponse opérationnelle à ce risque. La migration ECC vers S/4HANA mérite une mention particulière ; les organisations qui découvrent ce poste en cours de programme ont sous-estimé entre 40 et 60% de leur budget réel. Enfin, le dimensionnement du support post go-live est structurellement insuffisant dans la majorité des projets ; prévoir moins de 15% du coût d'implémentation expose l'organisation à des surcoûts d'exploitation significatifs dans les vingt-quatre premiers mois.

Un business case ERP ou GMAO solide repose sur trois composantes distinctes. La première est le coût total de possession sur cinq ans, calculé en intégrant les licences ou abonnements, l'implémentation, la migration de données, la formation, le support et les coûts d'infrastructure résiduels. La seconde est la valorisation des bénéfices attendus, exprimés en indicateurs financiers mesurables ; réduction du délai de clôture comptable, diminution du taux de rupture de stock, baisse du taux de saisie manuel dans la GMAO, réduction du temps de traitement des demandes de service. La troisième est l'analyse des risques budgétaires avec leurs probabilités et impacts quantifiés, permettant au COMEX de comprendre la fourchette réelle d'investissement plutôt qu'un chiffre unique qui sera systématiquement dépassé.

L'architecture de référence de l'usine connectée, telle que Gartner et LNS Research la définissent, s'articule en cinq niveaux. Le niveau 4 correspond à l'ERP, qui gère la planification, la finance et la supply chain. Le niveau 3,5 est occupé par le MES ou MOM, Manufacturing Operations Management, qui assure l'ordonnancement, la traçabilité, la qualité et la mesure de l'OEE. Le niveau 3 recouvre la supervision SCADA et HMI avec le monitoring temps réel des ateliers. Le niveau 2 correspond aux automates DCS et PLC. Le niveau 1 rassemble les capteurs IoT, les équipements edge et les protocoles de communication OPC-UA et MQTT. Le MES est la couche de traduction entre l'IT et l'OT. Sans lui, les données terrain restent inaccessibles à la décision métier et la planification ERP s'effectue sur des hypothèses plutôt que sur des réalités de production.

L'expérience d'audit d'une direction de maintenance industrielle gérant 80 000 équipements avec un taux de saisie GMAO de 23% illustre ce que l'absence de couche MES produit concrètement. 77% des interventions, des défaillances et des pièces consommées n'existent nulle part dans le système d'information. La maintenance préventive repose sur des calendriers arbitraires plutôt que sur l'historique réel des équipements. Les décisions d'investissement en remplacement d'actifs s'appuient sur des données incomplètes. Une alerte prédictive détectée à partir de l'historique de maintenance sur une pompe a évité un arrêt de production estimé à 200 000 euros sur une ligne de cogénération. Ce résultat a justifié à lui seul le budget de la phase de déploiement.

L'intégration IT/OT pose des enjeux de gouvernance que les projets ERP classiques ne rencontrent pas. La première difficulté tient à la coexistence de cycles de vie radicalement différents ; un ERP se renouvelle tous les dix à quinze ans, un automate industriel peut fonctionner trente à quarante ans. Les protocoles de communication des équipements anciens sont souvent propriétaires et incompatibles avec les standards modernes OPC-UA. La migration vers des architectures ouvertes suppose des investissements en infrastructure que les directions de production n'anticipent pas dans leurs plans pluriannuels. La deuxième difficulté concerne la cybersécurité OT. NIS2 classe les opérateurs industriels critiques parmi les entités essentielles soumises à ses obligations de sécurité. Les réseaux OT, historiquement conçus pour la disponibilité plutôt que pour la sécurité, présentent des vulnérabilités que les équipes IT ne sont pas toujours formées pour évaluer. 94% des entreprises industrielles maintiennent ou augmentent leurs investissements en cybersécurité OT selon les données Rockwell 2026. La troisième difficulté est organisationnelle ; la gouvernance des données de production suppose une collaboration entre les équipes maintenance, production, qualité et IT que les structures en silos de la plupart des organisations industrielles ne facilitent pas.

Siemens Opcenter Execution est le leader du Magic Quadrant Gartner MES pour la sixième année consécutive. Sa force principale est le Digital Thread qui relie le PLM à l'atelier sans rupture de données, couvrant l'électronique, les semi-conducteurs, la pharma et l'agroalimentaire. AVEVA MES et son PI System constituent la référence pour les industries de process continu ; énergie, chimie, pétrochimie. Le PI System d'OSIsoft, acquis par AVEVA puis par Schneider Electric, est le standard industriel pour la collecte et la contextualisation des données temps réel avec plus de 16 000 sites dans le monde. SAP Digital Manufacturing s'impose naturellement dans les environnements déjà équipés de SAP S/4HANA et SAP PP ; l'intégration native élimine les interfaces et garantit la cohérence des données entre planification et exécution. Rockwell Automation Plex représente l'option cloud-native par excellence, architecturé en multi-tenant SaaS dès sa conception, avec l'intégration de la GMAO Fiix dans sa suite. Tulip enfin occupe une position singulière avec son approche no-code centrée opérateur, particulièrement pertinente pour les industries réglementées comme les dispositifs médicaux et les sciences de la vie.

Celonis, leader mondial avec une valorisation de 13 milliards de dollars et une présence chez 60% du Fortune 500, a industrialisé une discipline qui existait en recherche académique depuis les années 2000. Le Process Mining extrait les event logs des bases de données opérationnelles ; l'historique horodaté de toutes les transactions, créations d'ordres de travail dans Maximo, changements de statut de commandes dans SAP, résolutions de tickets dans ServiceNow. Un algorithme de discovery reconstruit automatiquement les processus tels qu'ils s'exécutent réellement, avec leurs fréquences, leurs variantes et leurs déviations par rapport aux processus théoriques. La visualisation produite ressemble à un diagramme BPMN mais reflète la réalité de millions de cas, pas le contenu d'un manuel.

L'Execution Management System de Celonis va au-delà de l'analyse pour déclencher des actions correctrices en temps réel dans les systèmes sources. Une alerte envoyée à un gestionnaire quand une commande SAP dépasse son délai contractuel, une escalade créée automatiquement dans ServiceNow quand un processus de gestion des incidents dévie de son SLA, une mise en évidence dans l'interface ERP des bons de commande à risque pour l'utilisateur. La différence avec un outil de reporting classique est précisément là ; le Process Mining agit sur les processus en cours d'exécution, pas seulement sur les données post-mortem.

En environnement SAP, les cas d'usage les plus matures concernent le Purchase-to-Pay, l'Order-to-Cash et le Record-to-Report. Celonis identifie les commandes bloquées, les factures en attente de validation manuelle évitable, les doublons de paiement et les déviations du processus d'approbation. Les gains documentés chez les clients Fortune 500 se situent entre 5 et 15% de réduction du besoin en fonds de roulement et entre 20 et 40% de réduction du temps de traitement des factures. En environnement GMAO comme IBM Maximo ou Siveco Coswin, le Process Mining cartographie le flux réel des ordres de travail depuis la détection de la panne jusqu'à la clôture de l'intervention. Il identifie les équipements dont les ordres de travail génèrent systématiquement des reprises, les techniciens dont les clôtures sont incomplètes, et les pièces détachées dont l'approvisionnement rallonge structurellement les temps d'immobilisation. En environnement ITSM, l'analyse des processus de gestion des incidents et des changements permet de mesurer l'écart entre les SLA contractuels et leur respect réel, et d'identifier les étapes de routage qui concentrent les goulots d'étranglement.

NIS2 et DORA imposent aux organisations de surveiller et d'améliorer en continu leurs processus opérationnels critiques. Le Process Mining répond à ces exigences de façon structurelle. Pour NIS2, l'analyse des processus de gestion des incidents IT et de la chaîne d'approvisionnement identifie les déviations et les délais non conformes aux obligations de notification dans les 24 et 72 heures imposées par l'ANSSI. Pour DORA, applicable aux entités financières depuis janvier 2025, Celonis analyse les processus de gestion des incidents ICT, les délais de réponse et les patterns de récurrence pour alimenter le registre de résilience opérationnelle. L'avantage décisif par rapport aux approches d'audit traditionnelles est la continuité ; le Process Mining opère en temps réel sur les données de production, produisant une surveillance permanente conforme aux exigences de surveillance continue des deux textes réglementaires. Les certifications Celonis Analyst et Celonis Developer sont aujourd'hui reconnues par les équipes de conformité des grandes institutions financières européennes comme un standard de qualification pour les responsables de projet de conformité réglementaire.

COBIT 2019, publié par l'ISACA, est le cadre de référence mondial de la gouvernance et du management des systèmes d'information. Il repose sur une distinction fondamentale que la plupart des organisations peinent à appliquer ; la gouvernance (qui relève du conseil d'administration et de la direction générale, et concerne la définition des objectifs, l'évaluation des options et la surveillance) et le management (qui relève de la DSI et des responsables opérationnels, et concerne la planification, la construction, l'exécution et le suivi). Cette distinction structure l'ensemble du cadre en deux grandes familles de domaines ; EDM (Evaluate, Direct, Monitor) pour la gouvernance, et APO, BAI, DSS, MEA pour le management.

L'apport central de COBIT 2019 est la cascade des objectifs. Les objectifs stratégiques de l'organisation se déclinent en objectifs de gouvernance des SI, qui se décomposent eux-mêmes en objectifs d'alignement, lesquels permettent d'identifier les processus et les pratiques prioritaires pour l'organisation. Cette cascade garantit que chaque décision IT peut être reliée à un objectif de l'organisation. Sans elle, les investissements SI flottent dans un espace politique où le département le mieux représenté au COMEX emporte les arbitrages budgétaires.

COBIT 2019 introduit également une grille de conception tenant compte des facteurs contextuels de l'organisation ; sa taille, son secteur, sa stratégie de conformité, son appétit pour le risque. Deux organisations du même secteur peuvent légitimement avoir des architectures COBIT différentes selon leur contexte. C'est ce qui distingue COBIT d'un modèle prescriptif ; il est adaptatif par construction.

Les cinq objectifs de gouvernance des domaines EDM sont ; EDM01 (garantir l'établissement et le maintien du cadre de gouvernance), EDM02 (garantir la délivrance de valeur), EDM03 (garantir l'optimisation des risques), EDM04 (garantir l'optimisation des ressources) et EDM05 (garantir l'engagement des parties prenantes). Ces cinq objectifs constituent la structure minimale de toute gouvernance des SI sérieuse, quelle que soit la taille de l'organisation.

COSO a produit deux cadres qui structurent la gouvernance d'entreprise depuis les années 1990. Le premier, l'Internal Control Integrated Framework, définit les cinq composantes du contrôle interne ; l'environnement de contrôle (le "tone at the top", la culture de l'organisation vis-à-vis du contrôle), l'évaluation des risques (l'identification et l'analyse des risques susceptibles d'empêcher l'atteinte des objectifs), les activités de contrôle (les politiques et procédures qui garantissent l'exécution des directives), l'information et la communication (les systèmes qui permettent d'identifier, de saisir et de communiquer les informations pertinentes), et le pilotage (la surveillance continue de l'efficacité du contrôle interne). Le second cadre, l'ERM (Enterprise Risk Management), étend cette approche à la gestion des risques d'entreprise dans sa globalité.

Ce qui distingue COSO dans l'écosystème des référentiels de gouvernance, c'est son audience naturelle ; les auditeurs financiers, les commissaires aux comptes, les conseils d'administration, les directions financières. Quand un RSSI ou un directeur des SI formule ses recommandations dans le langage de COBIT, il parle à ses pairs informatiques. Quand il les formule dans le langage de COSO, il parle aux décideurs qui signent les budgets. Cette traduction n'est pas un exercice rhétorique ; c'est une condition d'efficacité.

COSO est également le cadre de référence de la conformité Sarbanes-Oxley pour le contrôle interne sur le reporting financier. Les auditeurs des grandes entreprises cotées américaines utilisent COSO comme grille d'évaluation des contrôles. Les SI qui supportent les processus financiers sont donc directement concernés par COSO, qu'ils le sachent ou non.

TOGAF, publié par The Open Group et régulièrement mis à jour (TOGAF Standard version 10 publiée en 2022), est le cadre de référence mondial de l'architecture d'entreprise. Il répond à une question que COBIT ne pose pas directement ; quel SI construire pour que l'organisation reste capable d'évoluer dans cinq à dix ans ? Il structure l'architecture d'entreprise en quatre domaines interdépendants ; l'architecture métier (les processus, les capacités organisationnelles et les parties prenantes), l'architecture des données (les actifs informationnels, leur gouvernance et leur cycle de vie), l'architecture des applications (le paysage applicatif et les services qu'il fournit), et l'architecture technique (l'infrastructure qui supporte le tout).

La méthode centrale de TOGAF est l'ADM, Architecture Development Method ; un cycle itératif de phases qui guide les architectes depuis la définition de la vision architecturale jusqu'à la gouvernance de l'implémentation. Chaque phase produit des livrables précis, examine les exigences de toutes les parties prenantes, et s'assure de la cohérence entre les quatre niveaux d'architecture. Ce qui rend l'ADM précieux, c'est qu'il empêche les décisions d'architecture d'être prises de façon isolée ; une décision technique ne peut pas contredire une exigence de l'architecture métier sans un arbitrage formalisé.

TOGAF est complémentaire de COBIT de façon très précise ; COBIT gouverne le SI existant, TOGAF conçoit le SI cible. Une organisation qui gouverne bien son SI actuel sans vision architecturale gère avec rigueur un système qui va dans la mauvaise direction. Une organisation qui a une belle architecture cible sans gouvernance opérationnelle ne parvient jamais à l'atteindre.

ISO 38500, publiée en 2008 et révisée en 2015 et 2024, est la norme internationale de gouvernance des technologies de l'information pour les organisations. Elle s'adresse explicitement aux dirigeants, directeurs et décideurs non informaticiens plutôt qu'aux techniciens. C'est sa première originalité ; c'est une norme de gouvernance destinée aux gouvernants, pas aux opérationnels.

ISO 38500 repose sur six principes fondamentaux. La responsabilité ; chaque individu et chaque groupe doit accepter et assumer la responsabilité de ses actions en matière d'IT. La stratégie ; la stratégie IT de l'organisation doit satisfaire les besoins actuels et futurs de l'organisation. L'acquisition ; les acquisitions IT doivent être fondées sur une analyse appropriée et une prise de décision continue et transparente. La performance ; l'IT doit être adaptée à l'objectif de soutien à l'organisation, fournissant les services, les niveaux de service et la qualité de service requis. La conformité ; l'IT doit se conformer à toutes les législations et réglementations obligatoires. Le comportement humain ; les politiques, pratiques et décisions IT doivent démontrer le respect des personnes et reconnaître les besoins actuels et émergents de toutes les personnes impliquées.

Le modèle d'ISO 38500 définit trois tâches de gouvernance ; évaluer l'utilisation actuelle et future des SI, orienter la préparation et la mise en oeuvre des plans et des politiques, et surveiller la conformité aux politiques et les performances par rapport aux plans. Ces trois tâches forment un cycle continu que COBIT appelle en écho évaluer-diriger-surveiller (EDM). Les deux référentiels sont donc alignés dans leur logique, ISO 38500 apportant la légitimité d'une norme internationale et COBIT apportant le détail opérationnel.

ITIL 4, publié par Axelos en 2019, est la quatrième version du cadre de référence mondial de la gestion des services IT. Par rapport à ITIL v3, il introduit trois évolutions majeures. La première est le Service Value System (SVS), une vision globale de la façon dont les composants et les activités d'une organisation travaillent ensemble pour créer de la valeur. La deuxième est la Service Value Chain (SVC), une chaîne de valeur des services articulée en six activités ; planifier, améliorer, engager, concevoir et transitionner, obtenir et construire, livrer et soutenir. La troisième est l'intégration des approches agiles, DevOps et Lean aux côtés des approches ITSM traditionnelles.

ITIL 4 définit trente-quatre pratiques de gestion des services, réparties en trois catégories ; les pratiques de management général (comme la gestion des risques, la gestion des connaissances, la gestion des fournisseurs), les pratiques de management des services (comme la gestion des incidents, la gestion des problèmes, la gestion des changements, le centre de services), et les pratiques de management technique (comme la gestion des déploiements, la gestion des infrastructures et des plateformes). Chaque pratique est décrite avec ses activités, ses rôles, ses métriques et ses interactions avec les autres pratiques.

Les quatre guiding principles d'ITIL 4 sont des repères universels applicables à n'importe quel contexte ; se focaliser sur la valeur, commencer où on en est, progresser de façon itérative avec du feedback, collaborer et promouvoir la visibilité, penser et travailler de façon holistique, rester simple et pratique, et optimiser et automatiser. Ces principes permettent aux organisations d'adapter ITIL à leur contexte sans en trahir l'esprit.

Ce qu'ITIL ne fait pas ; il ne certifie pas les organisations, il ne définit pas d'exigences légales, il ne prescrit pas de solutions technologiques. C'est un guide. Une organisation qui suit ITIL avec rigueur peut néanmoins être très mauvaise si elle applique les pratiques sans en comprendre le sens. ITIL est un outil ; son efficacité dépend de qui l'utilise et comment.

ISO/IEC 20000-1, dont la version actuelle date de 2018, est la norme internationale de management des services IT. Elle définit les exigences qu'une organisation doit satisfaire pour établir, mettre en oeuvre, maintenir et améliorer continuellement un système de management des services IT (SMIT). Ces exigences sont organisées en neuf clauses ; contexte de l'organisation, leadership, planification, support, opération, évaluation des performances, amélioration, et conception et transition des services nouveaux ou modifiés.

La certification ISO 20000 est délivrée par un organisme de certification accrédité après un audit en deux phases ; un audit documentaire qui vérifie que le SMIT est bien défini et documenté, puis un audit terrain qui vérifie que les pratiques sont réellement appliquées. La certification est valide trois ans avec des audits de surveillance annuels. Ce cycle garantit que la certification n'est pas un trophée figé mais un état maintenu dans la durée.

La relation entre ISO 20000 et ITIL 4 est celle d'une norme et d'un guide méthodologique ; ISO 20000 définit quoi atteindre, ITIL 4 décrit comment le faire. Une organisation qui suit ITIL 4 avec maturité dispose d'un excellent socle pour préparer une certification ISO 20000. Mais ITIL 4 ne remplace pas ISO 20000 : on peut appliquer ITIL sans jamais se faire certifier, et on peut obtenir la certification ISO 20000 en utilisant d'autres approches qu'ITIL.

Le Project Management Body of Knowledge, publié par le Project Management Institute, en est à sa septième édition (2021). Cette dernière version marque un changement de paradigme ; PMBOK 7 passe d'une approche par processus (définie par dix domaines de connaissance ; intégration, périmètre, calendrier, coûts, qualité, ressources, communications, risques, approvisionnements, parties prenantes) à une approche par principes (douze principes de management de projet) et par domaines de performance (huit domaines ; parties prenantes, équipe, approche de développement et cycle de vie, planification, travail du projet, délivrance, mesure, incertitude). Cette évolution reflète une réalité ; les projets modernes ne sont plus uniquement prédictifs. Ils intègrent des approches agiles, hybrides, adaptatives.

PMBOK est le référentiel de certification PMP (Project Management Professional), l'une des certifications les plus reconnues mondialement en management de projet. Il constitue le socle de connaissance exigé pour l'examen PMP, mais sa valeur dépasse la certification ; c'est une encyclopédie du management de projet qui couvre l'ensemble des situations qu'un chef de projet peut rencontrer, des plus simples aux plus complexes.

Projects in Controlled Environments, développé initialement par l'administration britannique dans les années 1980 et aujourd'hui publié par PeopleCert, est une méthode de management de projet basée sur sept principes, sept thèmes et sept processus. Les sept principes sont non négociables ; justification continue par un business case (le principe le plus distinctif de Prince2), apprendre de l'expérience, rôles et responsabilités définis, management par séquences, management par exception, focus sur les produits, adaptation à l'environnement du projet. Si un projet ne respecte pas ces sept principes, il n'est pas géré selon Prince2, quelle que soit l'intention affichée.

La force distinctive de Prince2 est le business case continu. À chaque fin de séquence, le projet doit démontrer qu'il reste justifié ; que les bénéfices attendus sont toujours réalisables, que le projet est toujours faisable et que les options envisagées sont toujours souhaitables. Si le business case ne tient plus, Prince2 impose d'arrêter le projet ou de le réorienter. Cette discipline est précisément ce qui manque dans la majorité des projets IT qui dérivent ; non pas la méthode au lancement, mais la justification continue à chaque étape.

Le Lean, issu du Toyota Production System développé dans les années 1940-1950 par Taiichi Ohno et Shigeo Shingo, est une philosophie d'amélioration continue fondée sur l'élimination des gaspillages (muda en japonais) et la création de valeur pour le client. Il identifie sept types de gaspillages originels dans la production ; la surproduction, l'attente, le transport inutile, le surtraitement, les stocks excessifs, les mouvements inutiles, et les défauts. Une huitième forme de gaspillage a été ajoutée par les praticiens du Lean appliqué aux services ; la non-utilisation des talents humains.

Appliqué aux systèmes d'information, le Lean se traduit par la cartographie des flux de valeur (value stream mapping) pour identifier les étapes qui créent de la valeur et celles qui constituent des gaspillages dans les processus IT. Un ticket de support qui attend dans une file sans traitement est un gaspillage d'attente. Une application développée sans besoin utilisateur réel est une surproduction. Une fonctionnalité trop complexe pour un besoin simple est du surtraitement. Le Lean invite à les éliminer systématiquement, non pas pour faire des économies mais pour libérer de la capacité au service de la création de valeur réelle.

Le Six Sigma, développé chez Motorola dans les années 1980 et popularisé par General Electric sous Jack Welch dans les années 1990, est une méthode de réduction des défauts et de la variabilité des processus fondée sur l'analyse statistique. Le nom vient de la notation sigma (σ) qui mesure la dispersion statistique ; atteindre le niveau six sigma signifie ne produire que 3,4 défauts par million d'opportunités, soit une quasi-perfection. La méthode s'articule autour du cycle DMAIC : Définir le problème et les objectifs, Mesurer les performances actuelles, Analyser les causes racines, Améliorer le processus par des solutions ciblées, et Contrôler pour maintenir les gains obtenus dans la durée.

L'articulation Lean Six Sigma, aujourd'hui la forme la plus répandue, combine la vitesse et la simplification du Lean avec la rigueur statistique du Six Sigma. Le Lean identifie les gaspillages et accélère les flux ; le Six Sigma réduit la variabilité et les défauts sur les processus ainsi optimisés. Dans les environnements Fortune 100 où j'ai exercé, cette combinaison était une obligation opérationnelle ; chaque responsable de processus était formé et devait appliquer ces disciplines. Le résultat mesurable était une réduction des coûts opérationnels, une amélioration de la qualité de service, et une base de données terrain qui alimentait les décisions stratégiques.

ISO/IEC 27001, dont la version actuelle date de 2022, est la norme internationale de référence pour le management de la sécurité de l'information. Elle définit les exigences pour établir, mettre en oeuvre, maintenir et améliorer continuellement un Système de Management de la Sécurité de l'Information (SMSI). Elle s'articule en dix clauses structurées selon le cycle Plan-Do-Check-Act, et en une Annexe A qui liste 93 mesures de sécurité organisées en quatre thèmes ; organisationnel (37 mesures), personnes (8 mesures), physique (14 mesures) et technologique (34 mesures). La version 2022 a réduit le nombre de mesures par rapport à la version 2013 (qui en comptait 114) et les a réorganisées dans ces quatre thèmes plus intuitifs.

La certification ISO 27001 est délivrée par un organisme accrédité après deux phases d'audit. L'audit de phase 1 vérifie que le SMSI est documenté et que l'organisation a défini son périmètre, réalisé son évaluation des risques et défini ses objectifs de sécurité. L'audit de phase 2 vérifie l'implémentation effective des mesures et l'efficacité du SMSI. La certification est ensuite maintenue par des audits de surveillance annuels et un audit de renouvellement tous les trois ans. Ce cycle est conçu pour garantir que la certification reflète un état réel et maintenu, pas une situation figée au moment de l'audit initial.

Ce que ISO 27001 n'est pas ; ce n'est pas une garantie de sécurité absolue. C'est la démonstration qu'une organisation a mis en place un système de management structuré pour identifier ses risques, implémenter des mesures proportionnées et améliorer continuellement son niveau de sécurité. Une organisation certifiée peut néanmoins subir une cyberattaque. Ce qui change, c'est qu'elle dispose d'un cadre pour y répondre, en tirer des leçons et améliorer sa posture.

ISO/IEC 27002:2022 est le code de bonne pratique pour les mesures de sécurité de l'information. Il détaille, pour chacune des 93 mesures listées dans l'Annexe A d'ISO 27001, les modalités de mise en oeuvre, les objectifs visés, les conseils d'implémentation et les informations complémentaires. ISO 27002 est le "comment faire" d'ISO 27001 pour chaque mesure. Il n'est pas certifiable indépendamment ; une organisation ne peut pas être certifiée ISO 27002. En revanche, c'est la référence opérationnelle que les responsables sécurité utilisent pour implémenter les contrôles de leur SMSI.

La version 2022 d'ISO 27002 introduit deux innovations importantes. La première est l'attribution d'attributs à chaque mesure ; type de contrôle (préventif, détectif, correctif), propriétés de sécurité de l'information (confidentialité, intégrité, disponibilité), concepts de cybersécurité (identifier, protéger, détecter, répondre, récupérer), capacités opérationnelles et domaines de sécurité. Ces attributs permettent aux organisations de trier et de prioriser les mesures selon leur contexte. La deuxième innovation est l'ajout de onze nouvelles mesures qui n'existaient pas dans la version 2013, portant notamment sur l'intelligence des menaces, la sécurité du cloud, la confidentialité et la protection des données personnelles, et la surveillance de la sécurité physique.

ISO/IEC 27005:2022 fournit les lignes directrices pour la gestion des risques liés à la sécurité de l'information. Elle s'appuie sur les concepts généraux d'ISO 31000 (la norme universelle de management des risques) et les applique spécifiquement au domaine de la sécurité de l'information. Elle n'est pas certifiable en tant que telle, mais elle est indispensable pour toute organisation qui veut mettre en oeuvre ISO 27001 de façon sérieuse, car ISO 27001 exige une évaluation des risques sans préciser de méthode.

ISO 27005 couvre le processus complet de gestion des risques de sécurité ; l'établissement du contexte (définir les critères d'évaluation et d'acceptation des risques), l'identification des risques (identifier les actifs, les menaces, les vulnérabilités et les impacts), l'analyse des risques (estimer la vraisemblance et les conséquences), l'évaluation des risques (prioriser selon les critères définis), le traitement des risques (modifier, éviter, transférer, accepter), et la communication et la surveillance. En France, ISO 27005 est compatible et complémentaire avec la méthode EBIOS Risk Manager de l'ANSSI, qui est la méthode de référence pour les OIV et les entités soumises à NIS2.

ISO 31000:2018 est la norme internationale de management des risques. Elle n'est pas certifiable ; aucun organisme ne délivre de certification ISO 31000 à une organisation. Son rôle est différent ; c'est un méta-référentiel qui fournit les principes, le cadre et le processus universels de la gestion des risques, applicables à toute organisation quelle que soit sa taille, son secteur ou son type de risques. Elle est intentionnellement générique pour permettre à chaque organisation de l'adapter à son contexte.

ISO 31000 articule la gestion des risques en trois niveaux. Les principes d'abord ; huit principes qui définissent ce qu'est une gestion des risques efficace (intégrée, structurée, adaptée au contexte, inclusive, dynamique, basée sur les meilleures informations disponibles, tenant compte des facteurs humains et culturels, et soutenant l'amélioration continue). Le cadre ensuite ; la structure qui intègre la gestion des risques dans l'organisation (leadership et engagement, intégration, conception, mise en oeuvre, évaluation et amélioration). Le processus enfin ; communication et consultation, établissement du contexte, évaluation des risques (identification, analyse et évaluation), traitement des risques, et surveillance et revue.

La position d'ISO 31000 dans l'écosystème normatif est celle d'un pont ; toutes les normes sectorielles de gestion des risques (ISO 27005 pour la sécurité, ISO 14091 pour les risques climatiques, ISO 22000 pour la sécurité alimentaire) s'y réfèrent explicitement comme fondation commune. Maîtriser ISO 31000 permet de comprendre la logique sous-jacente de toutes ces normes sectorielles, et d'éviter de traiter chaque domaine de risque comme un silo indépendant.

ISO 22301:2019 est la norme internationale de système de management de la continuité d'activité (SMCA). Elle est certifiable ; une organisation peut faire auditer son SMCA par un organisme accrédité et obtenir la certification ISO 22301. Elle définit les exigences pour planifier, établir, mettre en oeuvre, exploiter, surveiller, revoir, maintenir et améliorer continuellement un système de management documenté afin de se protéger des incidents perturbateurs, de réduire leur probabilité d'occurrence, de s'y préparer, d'y répondre et d'assurer la reprise d'activité dans les délais définis.

Les concepts centraux d'ISO 22301 sont le BIA (Business Impact Analysis ou Analyse d'Impact sur l'Activité), le RTO (Recovery Time Objective, délai maximal acceptable de reprise d'une activité) et le RPO (Recovery Point Objective, point maximal acceptable de perte de données). Le BIA identifie les activités critiques de l'organisation, le RTO définit le délai maximal acceptable d'interruption de chacune, et le RPO définit la quantité maximale acceptable de données perdues. Ces trois paramètres définissent les exigences que le plan de continuité doit satisfaire.

Pour les systèmes d'information, ISO 22301 se traduit concrètement par le Plan de Reprise d'Activité informatique (PRA) et le Plan de Continuité Informatique (PCI). Le PRA couvre les scénarios de sinistre grave (destruction d'un datacenter, cyberattaque majeure) et définit comment reprendre les systèmes critiques dans le délai RTO en restaurant les données jusqu'au point RPO. Le PCI couvre les scénarios de dégradation partielle et définit comment maintenir les activités essentielles pendant l'incident. Aucune organisation sérieuse ne peut se contenter de déclarer avoir un PRA sans l'avoir testé ; ISO 22301 exige des exercices réguliers et documentés.

Le Règlement Général sur la Protection des Données (RGPD), entré en application en mai 2018, est le cadre réglementaire de référence pour la protection des données personnelles dans l'Union Européenne. Il s'applique à toute organisation, quelle que soit sa taille ou son secteur, qui traite des données personnelles de résidents de l'UE, y compris des organisations situées hors de l'UE si elles traitent des données de résidents européens. Les sanctions peuvent atteindre 20 millions d'euros ou 4% du chiffre d'affaires mondial annuel pour les violations les plus graves.

Pour les systèmes d'information, le RGPD a des implications directes sur l'architecture, le développement et la gouvernance des données. Le principe de privacy by design impose que la protection des données soit intégrée dès la conception des systèmes et des processus, non ajoutée après coup. Le principe de minimisation impose de ne collecter que les données strictement nécessaires à la finalité déclarée. Les droits des personnes (accès, rectification, effacement, portabilité, opposition) imposent des fonctionnalités spécifiques dans les applications. La notion de registre des traitements impose de documenter chaque traitement de données personnelles, ses finalités, sa base légale et ses mesures de sécurité. Et la désignation d'un Délégué à la Protection des Données (DPO) est obligatoire pour certaines organisations.

La directive NIS2 (Network and Information Security 2), entrée en vigueur en janvier 2023 avec une échéance de transposition nationale en octobre 2024, représente un changement de paradigme dans la réglementation européenne de la cybersécurité. Elle élargit considérablement le périmètre de NIS1 (qui ne couvrait que quelques centaines d'organisations en France) pour couvrir potentiellement entre 15 000 et 18 000 entités françaises selon l'ANSSI, dans dix-huit secteurs répartis entre entités essentielles et entités importantes. Les sanctions peuvent atteindre 10 millions d'euros ou 2% du chiffre d'affaires mondial pour les entités essentielles.

L'article 20 de NIS2 est le plus novateur et le plus contraignant pour les dirigeants ; il impose que les organes de direction des entités régulées approuvent les mesures de gestion des risques de cybersécurité et peuvent être tenus personnellement responsables en cas de non-respect. C'est la fin de la délégation totale de la cybersécurité à la DSI ou au RSSI : la direction générale est désormais légalement impliquée. NIS2 impose également des mesures techniques et organisationnelles dans dix domaines (politiques de risques, gestion des incidents, continuité d'activité, sécurité de la chaîne d'approvisionnement, hygiène cyber, cryptographie, ressources humaines, authentification, communication sécurisée) et une obligation de notification d'incident significatif dans les 24 heures (alerte initiale) puis 72 heures (rapport détaillé).

Le Digital Operational Resilience Act, applicable depuis janvier 2025, est un règlement européen qui s'applique exclusivement au secteur financier ; banques, compagnies d'assurance, entreprises d'investissement, prestataires de services de paiement, plateformes de cryptoactifs, et leurs prestataires TIC critiques (fournisseurs cloud, éditeurs de logiciels critiques). Il vise à garantir que les entités financières peuvent résister, répondre et se remettre de tous types de perturbations et incidents liés aux TIC. Les sanctions peuvent atteindre 1% du chiffre d'affaires journalier moyen mondial.

DORA impose cinq piliers d'exigences ; la gestion du risque TIC (cadre de gestion intégré, gouvernance, stratégie de résilience), la gestion, la classification et le reporting des incidents TIC (détection, classification, notification aux autorités), les tests de résilience opérationnelle numérique (TLPT, Threat-Led Penetration Testing, pour les entités les plus systémiques), la gestion du risque tiers lié aux TIC (surveillance des prestataires critiques, clauses contractuelles obligatoires, stratégie de sortie), et le partage d'informations sur les cybermenaces. DORA s'applique conjointement avec NIS2 pour les entités financières ; les deux sont complémentaires et non substituables.

L'AI Act européen, adopté en juin 2024 et entrant progressivement en application jusqu'en 2027, est la première réglementation mondiale sur l'intelligence artificielle. Il classe les systèmes d'IA en quatre niveaux de risque avec des obligations proportionnées. Les systèmes à risque inacceptable (manipulation cognitive, notation sociale par les autorités publiques, identification biométrique en temps réel dans les espaces publics sauf exceptions) sont interdits. Les systèmes à risque élevé (IA dans les infrastructures critiques, les dispositifs médicaux, les processus d'emploi, les décisions judiciaires, les systèmes de migration) sont autorisés mais soumis à des exigences strictes de transparence, de documentation, de gestion des risques et d'enregistrement dans une base de données EU. Les systèmes à risque limité (chatbots, deepfakes) ont des obligations de transparence envers les utilisateurs. Les systèmes à risque minimal (jeux vidéo, filtres anti-spam) ne sont pas soumis à obligations spécifiques.

Le Data Act européen, applicable depuis septembre 2025, régule l'accès aux données générées par les objets connectés et les services connexes. Il impose que les fabricants conçoivent leurs produits pour permettre aux utilisateurs d'accéder facilement à leurs données, qu'ils puissent les partager avec des tiers de leur choix, et que les prestataires de services cloud facilitent la portabilité des données et la réversibilité. Pour les architectures SI, le Data Act a des implications directes sur la conception des systèmes d'information industriels, des plateformes IoT et des contrats cloud ; les clauses de réversibilité et de portabilité des données ne sont plus optionnelles.

Sarbanes-Oxley (SOX), adoptée aux États-Unis en 2002 à la suite des scandales Enron et WorldCom, est une loi fédérale américaine qui s'applique aux entreprises cotées sur les marchés américains et à leurs filiales mondiales. Sa section 404 est la plus impactante pour les SI : elle impose aux dirigeants de certifier annuellement l'efficacité des contrôles internes sur le reporting financier, et aux auditeurs externes de vérifier cette certification. Concrètement, tous les processus SI qui supportent le reporting financier (accès aux applications financières, séparation des fonctions dans les workflows d'approbation, traçabilité des modifications de données, continuité des systèmes critiques) doivent être documentés, testés et leur efficacité démontrée. SOX a forcé des milliers d'organisations à atteindre un niveau de maturité en gouvernance des SI qu'elles n'auraient jamais atteint spontanément.

ISO/IEC 42001, publiée en décembre 2023, est la première norme internationale spécifiquement dédiée au système de management de l'intelligence artificielle. Elle définit les exigences pour établir, mettre en oeuvre, maintenir et améliorer continuellement un SMAI dans une organisation qui développe, fournit ou utilise des systèmes d'IA. Sa structure suit le haut niveau de structure commun à toutes les normes ISO de management (identique à ISO 27001, ISO 9001, ISO 22301), ce qui facilite son intégration avec les autres systèmes de management déjà en place.

ISO 42001 couvre quatre dimensions complémentaires. La gouvernance de l'IA d'abord ; rôles et responsabilités, politique IA de l'organisation, objectifs et planification. L'évaluation de l'impact ensuite ; identification des systèmes d'IA déployés, évaluation de leur impact sur les parties prenantes internes et externes, classification par niveau de risque. La gestion des risques IA : identification des risques propres à l'IA (biais algorithmiques, explicabilité des décisions, dérive des modèles, sécurité des données d'entraînement) et traitement proportionné. Et l'amélioration continue ; surveillance des performances des systèmes d'IA, revues régulières et mise à jour des évaluations d'impact.

Ce qui distingue ISO 42001 d'un simple guide, c'est qu'elle est certifiable ; une organisation peut démontrer à des auditeurs externes que son approche de l'IA est structurée, documentée, évaluée et améliorée continuellement. Dans un contexte où la confiance dans les systèmes d'IA est un enjeu commercial et réglementaire croissant, cette certification peut devenir un avantage compétitif sur les marchés qui l'exigent, notamment les marchés publics et les secteurs régulés.

ISO/IEC 23894:2023 fournit des lignes directrices sur la gestion des risques spécifiques à l'intelligence artificielle. Elle s'appuie sur le cadre d'ISO 31000 (management des risques) et l'adapte aux caractéristiques propres des systèmes d'IA : les risques de biais algorithmiques et de discrimination, les risques d'explicabilité et de transparence des décisions automatisées, les risques de sécurité liés aux données d'entraînement et aux adversarial attacks, les risques de dérive des modèles en production, et les risques d'utilisation abusive ou de détournement des systèmes. Elle n'est pas certifiable, mais elle est une référence méthodologique indispensable pour toute organisation qui prend au sérieux la gouvernance de ses systèmes d'IA.

L'AI Act européen et ISO 42001 répondent à la même urgence ; gouverner les systèmes d'IA ; mais par des mécanismes fondamentalement différents. L'AI Act est contraignant ; il impose des obligations selon la classification des systèmes d'IA (interdits, à risque élevé, à risque limité, à risque minimal). ISO 42001 est volontaire ; c'est un cadre de management qu'une organisation choisit d'adopter pour structurer sa gouvernance de l'IA, sans y être légalement obligée.

Néanmoins, les deux se complètent de façon très pratique. ISO 42001 fournit un cadre de management qui couvre une grande partie des exigences de l'AI Act pour les systèmes à risque élevé ; documentation des systèmes d'IA, évaluation des risques, gouvernance interne, traçabilité, surveillance post-déploiement. Une organisation certifiée ISO 42001 dispose d'une base solide pour démontrer sa conformité à l'AI Act, même si la certification ne suffit pas à garantir la conformité réglementaire complète pour tous les systèmes à risque élevé.

Ce qui rend cette articulation stratégiquement importante, c'est le calendrier de l'AI Act. Les interdictions sont entrées en vigueur en février 2025. Les obligations pour les systèmes d'IA à usage général (GPAI) en août 2025. Les obligations pour les systèmes à risque élevé progressivement jusqu'en 2027. Les organisations qui ont anticipé en adoptant ISO 42001 dès 2024 ont une avance considérable sur celles qui découvrent leurs obligations au moment où les délais de conformité arrivent à échéance.