Piloter les chantiers des systèmes d'information en mode hybride : cybersécurité, valeur et ia responsable

Piloter un chantier de système d’information en mode hybride ne consiste plus à juxtaposer un cycle projet classique, des rituels agiles et quelques outils collaboratifs. Dans les organisations où les applications, les données, les services cloud, les composants d’IA et les obligations réglementaires évoluent simultanément, le pilotage doit relier des décisions de portefeuille à l’exécution quotidienne. Le chef de projet, le product owner, le responsable sécurité, les équipes techniques et les métiers ont besoin d’un langage commun pour arbitrer sans perdre de vue la finalité : délivrer une capacité utile, exploitable et durable.

Cette exigence est devenue plus forte avec l’industrialisation des usages d’intelligence artificielle. Un projet peut créer de la valeur par l’automatisation, l’assistance à la décision ou l’amélioration de l’expérience client, tout en introduisant de nouveaux risques sur les données, les accès, les modèles et les usages. Une démarche robuste ne traite donc pas la cybersécurité ou l’IA responsable comme des validations de fin de parcours. Elle organise le travail autour de trois repères continus : réduire le risque, démontrer la valeur et maîtriser la conformité. C’est cette logique qui rend le mode hybride réellement opérationnel.

Comprendre ce que recouvre un pilotage SI hybride

Le mode hybride répond à une réalité fréquente : certains éléments d’un programme exigent de la prédictibilité, tandis que d’autres nécessitent de l’apprentissage rapide. Le cadrage d’une migration, la contractualisation, l’architecture cible, la gestion des dépendances ou les exigences réglementaires appellent souvent des jalons formels. À l’inverse, une interface, un moteur de recommandation, un parcours utilisateur ou un cas d’usage d’IA gagnent à être testés par incréments. L’hybride n’est pas une absence de méthode ; c’est la capacité à appliquer le bon niveau de planification, de contrôle et d’itération à chaque composant.

Dans ce contexte, le pilotage doit éviter deux écueils. Le premier est le tunnel de spécifications : vouloir verrouiller trop tôt des usages dont la valeur réelle ne sera comprise qu’au contact des utilisateurs et des données. Le second est l’agilité sans garde-fous : multiplier les expérimentations sans propriétaire clairement identifié, sans critères de passage à l’échelle ni maîtrise des risques. Un programme SI reste un système de décisions, de dépendances et de responsabilités. Les équipes peuvent travailler en sprints, mais les risques de sécurité, de conformité, de budget et d’exploitation doivent être suivis avec une vision consolidée.

Une organisation efficace différencie donc les cadences. Une cadence courte sert à produire, tester et corriger : elle concerne les backlog, les démonstrations, les retours utilisateurs et les incidents. Une cadence de pilotage plus structurée sert à arbitrer les priorités, lever les blocages interéquipes, vérifier les risques majeurs et confirmer les engagements. Enfin, une cadence de gouvernance permet de prendre les décisions qui dépassent une équipe : acceptation d’un risque résiduel, évolution d’architecture, choix de fournisseur, changement de périmètre ou déploiement d’un usage sensible de l’IA.

Le rôle du pilote de projet est alors moins de « suivre des tâches » que de rendre les choix lisibles. Il doit faire apparaître ce qui est certain, ce qui est à expérimenter, ce qui dépend d’un tiers et ce qui ne peut pas être livré sans contrôle préalable. Cette transparence protège le calendrier autant que la qualité. Elle permet aussi d’expliquer aux sponsors pourquoi un contrôle de sécurité, une revue de données ou une validation juridique n’est pas un ralentissement administratif, mais une condition pour éviter de créer une dette risquée à l’échelle du SI.

Intégrer la cybersécurité dès le cadrage plutôt qu’en fin de projet

La cybersécurité doit faire partie du pilotage initial. Le NIST rappelle que les risques de cybersécurité associés aux systèmes d’IA rejoignent ceux du développement logiciel traditionnel, notamment autour de la confidentialité, de l’intégrité et de la disponibilité des données d’entraînement et des sorties. Cette continuité est importante : un projet IA ne dispense ni de maîtriser les identités, ni de protéger les interfaces, ni de tracer les actions, ni de préparer la continuité d’activité. Il ajoute au contraire des surfaces à examiner, telles que les jeux de données, les prompts, les connecteurs, les modèles et les mécanismes de restitution.

Concrètement, le cadrage devrait inclure une cartographie simple mais exploitable des actifs. Quelles données sont utilisées ? D’où viennent-elles ? Qui peut y accéder ? Quelles données sortent du système et vers quels outils ? Quels services externes sont appelés ? Quelles fonctions métier seraient dégradées si le service devenait indisponible ou si une réponse erronée était diffusée ? Ce travail ne requiert pas toujours un dossier lourd. En revanche, il doit produire des décisions explicites sur les données sensibles, les niveaux d’accès, les environnements, la journalisation et les responsables de validation.

Les contrôles doivent ensuite devenir des éléments du plan de livraison. Une revue de droits, un test de sécurité, une vérification de configuration, une procédure de réaction à incident ou une analyse de dépendance ne peuvent pas être relégués à une liste de souhaits. Chaque contrôle utile doit avoir un propriétaire, une échéance, une preuve attendue et un impact connu en cas de non-réalisation. Cette approche rend la sécurité pilotable : elle transforme une inquiétude générale en actions planifiées, puis en éléments vérifiables lors des comités de projet.

Le contexte justifie cette discipline. Le Verizon DBIR 2026 indique que les acteurs malveillants utilisent l’IA pour accélérer les étapes de leurs attaques, de l’identification de failles à l’écriture de malware. L’enjeu n’est pas de considérer chaque fonctionnalité d’IA comme dangereuse par nature, mais de reconnaître que le temps de réaction compte davantage. Dans un chantier hybride, il faut donc rapprocher la détection, la décision et la correction : critères d’alerte documentés, escalade claire, capacité à désactiver une fonction, et amélioration continue des contrôles à mesure que le produit et les menaces évoluent.

Faire de l’IA responsable une pratique de delivery

L’IA responsable devient concrète lorsqu’elle est traduite en pratiques de projet. Le NIST AI Risk Management Framework, version 1.0 publiée en 2023, demeure une référence opérationnelle pour structurer cette démarche. Le NIST indique qu’une révision est en cours ; il a également publié le 7 avril 2026 une note de cadrage sur un profil consacré à une « Trustworthy AI in Critical Infrastructure ». Pour un pilote SI, la leçon est claire : les cadres évoluent, mais le besoin de documenter, mesurer, gouverner et améliorer les risques liés à l’IA est déjà présent.

Le NIST place la propriété « Secure and Resilient » parmi les caractéristiques principales d’une IA digne de confiance. Cette formulation évite une vision réductrice de la responsabilité limitée à l’éthique déclarative ou à la qualité fonctionnelle. Un système peut sembler performant en démonstration et rester peu digne de confiance s’il est vulnérable à un détournement, s’il répond de manière imprévisible face à un incident, ou si l’équipe ne sait pas restaurer un fonctionnement maîtrisé. La sécurité, la résilience et la capacité de supervision doivent donc être inscrites dans la définition de fini d’une fonctionnalité.

Dans la pratique, une fiche de cas d’usage est un bon point de départ. Elle décrit le besoin métier, la décision ou l’action influencée par le système, les personnes concernées, les données mobilisées, les limites d’utilisation et le mode de contrôle humain. Elle précise aussi les scénarios où l’outil doit s’abstenir, transmettre à un expert ou afficher une information de prudence. Cette fiche n’est pas un document isolé : elle nourrit le backlog, les tests, les critères d’acceptation, les supports de formation et les procédures d’exploitation.

La vigilance doit inclure l’« adversarial ML ». En mars 2025, le NIST a publié une taxonomie et une terminologie relatives aux attaques et aux mitigations en apprentissage automatique adversarial. Pour les équipes de delivery, il est utile d’en tirer un réflexe : tester le système contre des entrées inattendues, des tentatives de contournement, des contenus manipulés et des usages hors périmètre. L’objectif n’est pas de promettre l’infaillibilité, mais d’identifier les comportements à risque, de définir des mesures de réduction réalistes et de savoir qui décide lorsqu’un compromis entre performance, sécurité et expérience utilisateur est nécessaire.

Gouverner les responsabilités et les décisions sensibles

Un programme hybride échoue souvent moins par manque de compétences que par ambiguïté des responsabilités. Le NIST AI RMF Core souligne que les dirigeants portent la responsabilité des décisions relatives aux risques de développement et de déploiement de l’IA. Cette responsabilité ne peut pas être transférée à un algorithme, à un fournisseur ou à une équipe technique. Elle implique que la direction formule l’appétence au risque, alloue les moyens nécessaires et arbitre les situations où les objectifs de délai, de coût, de conformité et de sécurité entrent en tension.

Le pilotage gagne à formaliser une matrice de décision plutôt qu’une simple liste d’intervenants. Les métiers définissent la valeur attendue et les conditions d’usage acceptable. Les équipes produit et projet organisent la livraison et la visibilité. Les architectes évaluent la cohérence des choix techniques et des intégrations. La cybersécurité évalue les menaces, les contrôles et le risque résiduel. Les fonctions juridique, conformité et protection des données éclairent les obligations applicables. L’exploitation prépare le support, la supervision et la continuité. La direction tranche les exceptions et accepte, lorsque cela est justifié, les risques qui restent.

Cette répartition doit être observable dans les rituels. Un comité de pilotage ne devrait pas se limiter à un état d’avancement vert, orange ou rouge. Il doit examiner les décisions attendues, les risques sans propriétaire, les hypothèses non validées et les dépendances qui affectent la valeur. Pour les usages d’IA, il est pertinent d’y ajouter les limites constatées, les résultats des évaluations, les incidents ou quasi-incidents, ainsi que les changements de données, de modèle ou de fournisseur. Une décision documentée protège la mémoire du programme et évite qu’un choix sensible repose sur des échanges informels.

L’OCDE rappelle dans son guide de due diligence pour une IA responsable publié en 2026 que la responsabilité demeure portée par les personnes, les gouvernements et les organisations, et non par l’IA elle-même. Cette position rejoint les besoins concrets des équipes : un outil peut assister une décision, mais il ne remplace pas le cadre de responsabilité. Le bon niveau d’intervention humaine dépend du contexte et de l’impact du cas d’usage. Le projet doit donc préciser qui supervise, qui peut corriger, qui peut suspendre le système et comment les utilisateurs signalent un résultat problématique.

Relier la valeur métier au risque mesurable

Un chantier SI doit être défendu par des résultats, pas uniquement par une promesse technologique. La valeur peut prendre plusieurs formes : temps gagné sur une opération, meilleure qualité de service, diminution des erreurs, accélération d’une décision, disponibilité accrue ou réduction d’un risque. Le point essentiel est de choisir un indicateur que les métiers reconnaissent et dont le suivi est possible. Une démonstration impressionnante ne suffit pas si personne ne peut expliquer quel problème elle résout, pour quels utilisateurs et dans quelles conditions elle produit un bénéfice durable.

La cybersécurité fait partie de cette équation économique. IBM a publié le 29 juillet 2026 que 25 % des violations malveillantes étaient alimentées par l’IA, en hausse de 56 % sur un an, avec un coût moyen de 6 millions de dollars pour ces incidents. Ces éléments ne permettent pas de calculer automatiquement le risque propre à chaque organisation, mais ils confirment qu’il serait imprudent de dissocier la décision d’investissement IA de la capacité à protéger les accès, les données et les processus. Un budget de contrôle n’est pas un coût étranger à la valeur : il contribue à rendre cette valeur soutenable.

Pour piloter utilement, il est préférable de distinguer les indicateurs de résultat des indicateurs de maîtrise. Les premiers répondent à la question : le cas d’usage apporte-t-il l’effet attendu ? Les seconds répondent à une autre question : le projet reste-t-il dans un niveau de risque acceptable ? Une équipe peut ainsi suivre l’adoption, le délai de traitement ou la qualité perçue, tout en suivant la couverture des accès, la résolution des vulnérabilités, la complétude de la traçabilité ou le traitement des alertes. Cette lecture à deux niveaux évite de sacrifier l’un au profit de l’autre.

Les travaux 2026 de Verizon et d’IBM convergent sur un point : à mesure que l’IA s’intègre aux processus métier et de sécurité, la qualité des contrôles d’accès, de la supervision et de la gouvernance devient déterminante. Le responsable de projet peut transformer cette idée en arbitrages simples. Avant d’étendre un pilote, il vérifie que les droits sont cohérents avec les usages réels. Avant de connecter une nouvelle source, il vérifie l’objectif, la légitimité et la traçabilité. Avant d’automatiser une décision, il vérifie le mécanisme de recours et de correction. La valeur croît mieux lorsque les conditions de maîtrise progressent au même rythme.

Anticiper l’AI Act, NIS 2 et la conformité dans la feuille de route

En Europe, la conformité IA doit désormais être considérée comme une dimension de gouvernance de projet. La Commission européenne précise que l’European AI Office et les autorités nationales sont responsables de l’application, de la supervision et de l’exécution de l’AI Act. Le déploiement du texte est progressif jusqu’au 2 août 2028. Les obligations liées aux modèles d’IA à usage général, ou GPAI, sont déjà applicables depuis le 2 août 2025. Pour les équipes SI, attendre la phase de mise en production pour poser les questions de qualification, de documentation ou de responsabilités expose à des reprises coûteuses.

Il est plus efficace d’intégrer un parcours de conformité à la feuille de route. Dès l’instruction du besoin, le projet peut identifier si un système d’IA est concerné, préciser le rôle de l’organisation dans la chaîne de valeur et recenser les composants tiers. Pendant la conception, il peut organiser la documentation, les exigences de sécurité, les informations destinées aux utilisateurs et les éléments de preuve. Pendant les tests, il peut vérifier les limites convenues et l’aptitude de l’organisation à superviser le système. Cette démarche ne remplace pas l’expertise juridique, mais elle donne à cette expertise les informations nécessaires au bon moment.

La Commission européenne indique aussi préparer avec l’ENISA un blueprint pour sécuriser l’accès à des systèmes d’IA avancés à des fins de cybersécurité, ainsi qu’une plateforme de test sécurisée pour les secteurs critiques. Cette orientation confirme l’intérêt d’environnements de test séparés, de jeux de données maîtrisés et de procédures d’accès proportionnées. Un projet qui expérimente vite n’a pas besoin d’expérimenter sans cadre. Il peut accélérer l’apprentissage tout en empêchant qu’une preuve de concept devienne, par simple inertie, un service exposé sans sécurité, sans propriétaire et sans capacité de surveillance.

La réglementation NIS 2 renforce également la dimension de résilience dans les décisions SI. L’ENISA indique que son rapport NIS Investments 2023 analyse l’allocation des budgets cybersécurité, le développement des capacités et la mise en conformité avec NIS 2, en tenant compte des tendances globales et de l’impact de l’IA. La logique budgétaire ne se limite donc plus à « sécuriser davantage ». Elle consiste à arbitrer des investissements en fonction de la résilience opérationnelle, de la conformité et de la capacité de l’organisation à absorber de nouveaux usages d’IA. Cela appelle une planification pluriéquipe, et non un financement ponctuel à la fin du projet.

Mettre en place un tableau de bord risque, valeur et conformité

Pour éviter que la gouvernance ne devienne abstraite, le programme peut s’appuyer sur trois familles de KPI : risque, valeur et conformité. Cet équilibre est cohérent avec les cadres du NIST, de l’ENISA, de l’OCDE et avec l’AI Act. Le KPI de risque ne résume pas toute la sécurité à un nombre unique : il donne une vision des risques ouverts, de leur criticité, de la couverture des contrôles et du délai de traitement. Le KPI de valeur relie les livrables aux effets métier attendus. Le KPI de conformité permet de suivre les obligations, les preuves et les décisions à obtenir avant chaque passage de jalon.

Un tableau de bord utile reste concis et actionnable. Pour le risque, il peut présenter les vulnérabilités critiques non traitées, les écarts d’accès, les dépendances sensibles et les risques résiduels en attente d’acceptation. Pour la valeur, il peut suivre l’usage réel, l’atteinte d’un objectif opérationnel ou la progression d’un bénéfice validé par le métier. Pour la conformité, il peut faire apparaître les analyses à conduire, les documents attendus, les validations nécessaires et les échéances réglementaires. Le bon indicateur est celui qui déclenche une discussion ou une décision, pas celui qui produit une apparence de précision.

La qualité des données de pilotage est tout aussi importante que le tableau lui-même. Chaque mesure doit avoir une définition partagée, une source identifiée, une fréquence de mise à jour et un responsable. Les équipes doivent pouvoir distinguer une donnée observée d’une estimation, un risque prouvé d’une hypothèse, une valeur déjà constatée d’un gain attendu. Cette discipline améliore la confiance entre les parties prenantes. Elle évite également qu’un comité soit mobilisé par des débats sur la fiabilité des chiffres au lieu de se concentrer sur les décisions qui permettront de corriger une trajectoire.

Le World Economic Forum souligne dans son édition 2026 que la valeur de l’IA en cybersécurité provient surtout de l’augmentation des experts, de l’accélération des décisions et du renforcement de la résilience, plutôt que de l’automatisation seule. Le tableau de bord doit refléter cette réalité. Il ne s’agit pas seulement de compter les tâches automatisées, mais de vérifier si les experts disposent d’informations plus exploitables, si les alertes sont mieux priorisées, si les décisions sont plus rapides et si l’organisation se rétablit mieux face à un incident. Technologie, compétences, processus et gouvernance doivent avancer ensemble pour défendre à « machine speed ».

Conduire le changement et préparer l’exploitation durable

Un projet n’est réellement livré que lorsqu’il peut être utilisé, supervisé et maintenu par les personnes qui en ont la charge. Cela est particulièrement vrai pour l’IA, où la qualité du résultat dépend souvent de la compréhension du contexte par les utilisateurs. Former ne signifie pas uniquement expliquer les fonctions d’un outil. Il faut aussi expliquer ses limites, les situations où une validation humaine est indispensable, les comportements à éviter et le canal de remontée des anomalies. Cette appropriation réduit les usages de contournement et donne au programme des retours indispensables pour améliorer le service.

La conduite du changement doit débuter avant le déploiement. Associer des utilisateurs représentatifs aux tests permet de confronter les hypothèses du projet aux situations réelles. Associer l’exploitation permet de préparer les procédures de support, la surveillance, les mises à jour et les modalités de suspension. Associer la sécurité et la conformité permet de rendre les contrôles compatibles avec les contraintes opérationnelles. Le résultat est souvent plus solide qu’une validation finale massive, car les problèmes sont découverts et traités au fil des itérations, avec un coût de correction plus maîtrisé.

Un plan d’exploitation doit notamment répondre à des questions simples : qui surveille le service, quels événements déclenchent une alerte, quelle est la procédure si le résultat devient douteux, comment un incident est-il analysé, et comment une évolution est-elle validée ? Dans le cas d’une IA, il faut aussi définir les conditions de mise à jour du modèle, des données, des consignes ou des connecteurs. Une modification apparemment mineure peut changer le comportement du système. La gestion du changement doit donc conserver une trace suffisante pour expliquer ce qui a été modifié, pourquoi, et avec quels résultats de vérification.

Cette approche rejoint la logique de due diligence promue par l’OCDE : la conformité et la création de valeur ne sont pas antagonistes lorsqu’elles sont intégrées dans les pratiques de gestion. Une organisation qui sait démontrer ses décisions, suivre ses risques et corriger ses écarts est mieux placée pour déployer l’IA de façon utile. Pour un chef de projet SI, l’objectif n’est pas d’ajouter de la bureaucratie. Il est de créer un dispositif proportionné, où chaque contrôle répond à un risque ou à une obligation identifiée, et où chaque expérimentation peut devenir un service fiable si sa valeur est confirmée.

En définitive, piloter des chantiers SI hybrides exige une gouvernance qui accepte l’incertitude sans abandonner la responsabilité. La cybersécurité doit être intégrée dès la conception, l’IA responsable doit se traduire en critères de delivery, et les décisions doivent rester attribuées à des personnes clairement mandatées. Les repères fournis par le NIST, l’ENISA, l’OCDE, la Commission européenne, le WEF, Verizon et IBM invitent à sortir d’une vision purement technique : le programme se pilote par la résilience, la qualité des décisions et la capacité à prouver ce qui est maîtrisé.

Le cadre le plus pragmatique consiste à maintenir, tout au long du cycle de vie, une lecture commune du risque, de la valeur et de la conformité. Cette grille aide à prioriser les backlogs, à construire les budgets, à animer les comités et à préparer l’exploitation. Elle permet surtout de faire de l’IA un levier d’augmentation des équipes et de performance durable, plutôt qu’une source de dette, d’exposition ou de promesses difficilement tenables. Dans un environnement où les attaques et les obligations évoluent vite, la qualité du pilotage devient elle-même un avantage opérationnel.