Mark Fetches, CTO de Spinnaker Support – Série d’entretiens

Mark Fetches est le directeur technique pour l’EMEA chez Spinnaker Support, où il conseille les organisations d’entreprise sur la stratégie technologique, la sécurité, le cloud, l’IA et les initiatives de transformation à grande échelle. Avec plus de 30 ans d’expérience en tant que consultant et dirigeant au sein d’Accenture, Deloitte et PwC, Mark a travaillé en étroite collaboration avec les dirigeants de l’équipe de direction et les conseils d’administration pour moderniser les environnements d’entreprise complexes et aligner les décisions technologiques sur les objectifs commerciaux à long terme. Basé au Royaume-Uni, il se spécialise dans l’aide aux organisations pour naviguer dans les défis de la technologie héritée, les risques opérationnels et la transformation numérique avec des conseils pratiques et axés sur les entreprises.

Spinnaker Support est un fournisseur mondial de premier plan de support logiciel tiers, de services gérés et de conseil en sécurité pour les entreprises qui utilisent des plateformes critiques telles qu’Oracle (ORCL ), SAP, JD Edwards et d’autres.

Vous avez passé plus de 20 ans à conseiller les entreprises chez Accenture, Deloitte et PwC avant de devenir CTO chez Spinnaker Support. En regardant en arrière sur ce parcours, quels sont les plus grands malentendus que les dirigeants ont eu systématiquement sur le risque technologique, et comment l’émergence de l’IA a-t-elle changé ces conversations ?

Je pense que le plus grand malentendu a toujours été que le risque technologique se situe à côté de l’entreprise et peut être géré comme une question spécialisée. Je n’ai jamais vraiment vu les choses de cette façon.

La plupart des risques graves que j’ai vus proviennent de choix de leadership. De combien de complexité on tolère. De combien on dépend de plates-formes anciennes ou de fournisseurs clés. De combien on pousse pour la vitesse. De si l’on fait vraiment confiance aux données sur lesquelles repose l’entreprise. La technologie est là où ces choix se manifestent, mais ce n’est généralement pas là où ils commencent.

Au fil des ans, j’ai vu de nombreux dirigeants se concentrer sur les choses évidentes telles que la cybersécurité, la conformité et la réduction des coûts. Ce sont des problèmes réels, bien sûr. Mais les risques qui ont tendance à prendre les entreprises au dépourvu sont souvent plus silencieux que cela. C’est la plate-forme que tout le monde sait être fragile mais qui continue de reporter son remplacement. C’est le problème de données que personne ne possède vraiment. C’est la dépendance sous-traitée qui semble efficace jusqu’à ce qu’elle devienne un goulet d’étranglement. Ce sont ces choses qui peuvent rester en arrière-plan pendant des années et devenir soudainement très visibles lorsque quelque chose se casse.

Je pense également qu’il y a eu une longue habitude de confondre la conformité avec la résilience. Ce ne sont pas les mêmes choses. Vous pouvez passer une audit et être encore beaucoup plus exposé que vous ne le pensez. Une liste de contrôle ne vous indique pas comment l’entreprise réagira sous pression, comment elle pourra se rétablir rapidement ou si les dirigeants voient vraiment clairement le problème pour agir.

Ce que l’IA a changé, c’est le niveau d’attention. Ces conversations se déroulaient autrefois plus bas dans l’organisation. Maintenant, elles sont au cœur des discussions dans la salle du conseil d’administration sur la croissance, la confiance, la productivité et la marque. C’est une très bonne chose. Mais cela a également introduit une nouvelle simplification, qui est l’idée que le modèle d’IA utilisé est le risque. Habituellement, c’est plus que cela. Les questions plus difficiles portent sur les données et la gouvernance qui l’entourent, les décisions qu’il influence et le point auquel le jugement humain doit encore compter.

Donc, si je devais le résumer, je dirais que le risque technologique n’a jamais vraiment été à propos de la technologie seule. Il a toujours été un reflet du jugement de leadership. L’IA a simplement rendu cela plus difficile à ignorer.

Les équipes de sécurité ont maintenant accès à plus d’informations sur les vulnérabilités que jamais auparavant, et pourtant, les organisations continuent de lutter avec la priorisation. Pourquoi pensez-vous que l’industrie a un problème de signal par rapport au bruit plutôt qu’un problème de détection ?

Je dirais que l’industrie n’est pas en manque de données sur les vulnérabilités. Elle est en manque de clarté.

La plupart des équipes de sécurité ont déjà plus que suffisamment d’informations, de sorties d’analyseurs, d’informations sur les menaces, de scores de gravité, de conseils de correction, de rapports d’exploitation. Le problème n’est pas de savoir s’ils peuvent trouver des faiblesses. C’est de savoir s’ils peuvent séparer celles qui pourraient vraiment nuire à l’entreprise de celles qui sont techniquement intéressantes mais moins conséquentes.

C’est pourquoi je le vois comme un problème de signal par rapport au bruit. La détection s’est améliorée énormément. Ce qui n’a pas suivi, c’est la capacité d’appliquer le contexte. Une vulnérabilité ne devient un véritable problème que lorsque vous comprenez où elle se situe, à quel point elle est exposée, à quel point l’actif est critique, quels contrôles compensatoires existent et quel serait l’impact commercial si elle était exploitée.

Dans la pratique, de nombreuses organisations recourent encore aux métriques les plus faciles à produire, comme les scores de gravité, les comptes de correctifs et les rapports de vieillissement. Ceux-ci sont utiles, mais ils ne sont pas les mêmes que le jugement humain. Une question à fort score dans un système interne de faible valeur peut importer beaucoup moins qu’une faiblesse notée plus basse située sur quelque chose de critique pour les opérations ou la face client.

Je ne pense donc pas que cela soit fondamentalement un problème de visibilité. C’est un problème de priorisation commerciale qui doit être appris par les équipes de sécurité. Nous sommes devenus très bons pour générer des résultats. Nous sommes moins constants pour traduire ces résultats en une courte liste d’actions que la direction peut soutenir avec confiance.

Et de mon point de vue, c’est le véritable changement que l’industrie doit encore faire, un déplacement de la mesure de ce que nous pouvons détecter vers la décision de ce qui compte vraiment en termes d’impact commercial.

Au niveau du conseil d’administration, c’est vraiment une question de traduction du risque, peut-on convertir l’exposition technique en un petit nombre de priorités d’actions commerciales claires ? Ceux qui peuvent le faire sont ceux qui passent du bruit au signal.

De nombreux fournisseurs de sécurité affirment que l’IA peut automatiquement prioriser les vulnérabilités et prédire les menaces. Où voyez-vous l’écart entre le récit marketing et ce que l’IA peut réaliser de manière réaliste aujourd’hui dans les environnements d’entreprise ?

Je pense que la façon la plus simple de le dire est que le marketing autour de cela tend à promettre un niveau de certitude que les environnements d’entreprise réels ne permettent simplement pas.

Les fournisseurs décrivent souvent l’IA comme si elle pouvait se démarquer du bruit, prendre en compte tout et dire de manière fiable à une équipe de sécurité ce qui compte le plus et ce qui est susceptible de se produire ensuite. C’est un argument de vente convaincant car chaque dirigeant de la sécurité veut moins de désordre et plus de confiance. Mais une fois que vous entrez dans une grande organisation, les choses sont rarement aussi simples que le laissent entendre les promesses.

L’IA peut certainement aider. Elle peut rassembler des modèles, réduire une partie de l’analyse manuelle et aider les équipes à traiter des volumes d’informations qui seraient autrement difficiles à gérer, et cela a une valeur réelle. Mais il y a une différence entre aider une équipe à aller plus vite et savoir, avec une précision fiable, ce qui devrait importer le plus dans cet environnement spécifique.

C’est là que l’écart apparaît. La plupart des entreprises sont remplies de contextes inégaux. Les inventaires d’actifs sont incomplets. La propriété n’est pas toujours claire. La criticité commerciale change. Les contrôles varient d’une partie de l’environnement à une autre. La qualité des données est mélangée. Si l’image de base est patchy, alors la sortie de l’IA le sera également, quelle que soit la qualité de l’interface.

Je pense que cela est particulièrement vrai lorsque les fournisseurs parlent de prédiction. Il y a une différence significative entre dire : « ce modèle semble risqué » et dire : « c’est ce qui se produira ensuite ». Le premier peut être utile. Le second est là où le langage dépasse souvent la réalité.

Donc, pour moi, l’IA est mieux comprise aujourd’hui comme un amplificateur, et non comme une autorité. Elle peut aider les équipes à trier, à corréler et à se concentrer. Ce qu’elle ne peut pas faire de manière constante, c’est remplacer le besoin de jugement humain, de connaissance locale et d’une compréhension claire de ce que l’entreprise se soucie vraiment.

C’est vraiment la division. Le récit suggère une certitude. La réalité est plus modeste et plus utile que l’hype si vous êtes honnête à ce sujet. L’IA peut améliorer la qualité et la rapidité de l’analyse, mais elle n’enlève pas la complexité de la prise de décision en matière de sécurité d’entreprise.

Spinnaker Support travaille étroitement avec les déploiements Oracle, SAP et JD Edwards. Qu’est-ce qui rend les environnements ERP hautement personnalisés particulièrement difficiles pour les outils de sécurité basés sur l’IA à comprendre et à évaluer avec précision ?

Ce qui rend ces environnements difficiles, c’est qu’après suffisamment d’années, ils cessent de se comporter comme des logiciels standard sur lesquels l’IA a été formée et commencent à se comporter plus comme un enregistrement de la façon dont l’entreprise fonctionne réellement.

J’ai vu cela être particulièrement vrai dans les domaines Oracle, SAP et JD Edwards fortement personnalisés. Sur le papier, vous regardez peut-être toujours une plate-forme connue. Dans la réalité, vous regardez souvent des années d’adaptations locales, de code personnalisé, d’intégrations héritées, de structures de permissions, de logique de rapport et de contournements créés pour des raisons opérationnelles très spécifiques. Pour un outil de sécurité basé sur l’IA, je crois que cela peut être difficile à lire avec une réelle confiance.

Beaucoup de ces outils fonctionnent mieux lorsque l’environnement est relativement cohérent et que les modèles sont plus faciles à comparer. Les environnements ERP hautement personnalisés sont rarement comme cela. La logique est plus emmêlée. La documentation est souvent incomplète. La propriété peut être répartie entre les équipes. Ce qui semble inhabituel peut être parfaitement intentionnel et ce qui semble ordinaire peut se révéler soutenir quelque chose de vraiment critique dans la finance, la chaîne d’approvisionnement ou les opérations.

C’est là que se trouve la difficulté. L’outil n’est pas seulement chargé de détecter une vulnérabilité ou une mauvaise configuration. Il est chargé de comprendre ce que ce problème signifie dans le contexte d’un processus commercial, d’une dépendance personnalisée ou d’une structure de contrôle qui peut n’exister nulle part ailleurs.

Et c’est un problème beaucoup plus difficile que ce que le marketing implique généralement. L’IA peut aider à mettre en évidence des modèles, réduire une partie de l’analyse manuelle et pointer les équipes vers des domaines qui méritent un examen plus approfondi, et cela a une valeur réelle. Mais s’il est demandé à un système automatisé d’interpréter cela seul dans un environnement dont le contexte est partiellement documenté, façonné par des années d’exceptions et profondément lié à la façon dont l’entreprise fonctionne, il y a une limite à la précision avec laquelle il peut le faire.

Donc, je pense que le véritable problème n’est pas de savoir si l’IA peut voir quelque chose. C’est de savoir si elle peut comprendre suffisamment du contexte environnant pour le juger correctement. Dans les environnements ERP hautement personnalisés, c’est toujours là que l’expertise humaine fait la différence.

L’un de vos arguments clés est que l’expertise humaine n’est pas un goulet d’étranglement à éliminer, mais une partie essentielle du processus de sécurité. Pouvez-vous partager des exemples où le jugement humain a identifié des risques que le moteur de priorisation basé sur l’IA aurait probablement manqué ?

Oui, absolument. Et pour moi, c’est là que les limites de la priorisation automatisée deviennent très évidentes.

Certains risques n’ont de sens que lorsque vous connaissez suffisamment l’environnement pour comprendre ce qui se cache derrière les données. Un système peut ne pas sembler particulièrement important de l’extérieur. Le score de vulnérabilité peut être sans intérêt. Mais quelqu’un qui connaît bien l’environnement peut savoir que cela soutient la paie, les rapports de fin de trimestre, une intégration fragile ou un processus commercial que l’entreprise ne peut simplement pas interrompre. Le signal dans les données peut sembler ordinaire. La conséquence réelle ne l’est pas.

J’ai également vu des cas où l’image des contrôles semble meilleure en théorie que dans la pratique. Un moteur d’IA pourrait supposer qu’un risque est réduit parce que la segmentation est en place, ou parce que l’accès est restreint, ou parce qu’un contrôle de surveillance existe. Mais une personne proche de l’environnement peut savoir qu’un contrôle est appliqué de manière incohérente, qu’un autre est contourné lorsque les opérations sont sous pression et qu’un troisième a simplement cessé d’être fiable. Ce type de lacune ne se manifeste pas toujours de manière claire dans le système d’enregistrement.

La même chose se produit dans les environnements personnalisés. Un script, un flux de travail ou un modèle de permissions peut sembler ordinaire si vous scannez des modèles à grande échelle. Pour quelqu’un qui comprend comment ce système a été adapté au fil du temps, le même détail peut se démarquer immédiatement comme une véritable source d’exposition.

Le timing compte également. Une vulnérabilité peut sembler gérable en isolation, puis devenir beaucoup plus grave parce que l’entreprise est en pleine migration, acquisition, date limite réglementaire ou période de pointe opérationnelle. Ce type de changement n’est pas toujours facile pour un moteur automatisé à interpréter avec le poids approprié.

Donc, lorsque je parle d’expertise humaine, je ne parle pas d’instinct de quelque manière que ce soit. Je parle de connaissance locale. De mémoire. De jugement. De la capacité de voir quand un petit problème technique est attaché à quelque chose de beaucoup plus conséquent.

C’est pourquoi je ne vois pas l’expertise humaine comme un goulet d’étranglement à éliminer. Je la vois comme la partie qui empêche une fausse confiance. L’IA peut aider à trier et à réduire les données. Mais les risques qui comptent le plus sont souvent ceux qui ne deviennent évidents que lorsque quelqu’un comprend vraiment comment fonctionne l’entreprise.

Alors que les organisations se précipitent pour adopter l’IA à travers les opérations de sécurité, quels sont les plus grands risques de sur-automatisation de la gestion des vulnérabilités et de l’évaluation de l’exposition ?

Le plus grand risque que je vois, c’est que vous créiez l’apparence de contrôle sans la réalité de vraiment comprendre que vous êtes en contrôle.

La gestion des vulnérabilités est l’un de ces domaines où l’automatisation est évidemment précieuse. À l’échelle de l’entreprise, vous avez besoin d’automatisation pour trouver des problèmes, corréler des données, prioriser en volume et maintenir l’ensemble du processus en mouvement. Aucune organisation sérieuse ne peut gérer cela manuellement.

Mais le danger vient lorsque l’automatisation commence à conduire le programme sans suffisamment de défis humains autour d’elle.

Le premier risque évident est la fausse priorisation. Si vous vous fiez trop lourdement au scoring automatisé, vous pouvez finir par traiter la gravité technique comme si elle était la même chose que le risque commercial. Ce n’est pas le cas. Une vulnérabilité critique sur un système isolé ou avec des contrôles compensatoires peut importer moins en pratique que une question notée plus basse située sur un système hautement exposé lié à un processus commercial critique.

Le deuxième risque que je vois est la perte de contexte. Les programmes automatisés ne sont que aussi bons que les données d’actifs, les données de propriété, la cartographie des dépendances et la gestion des exceptions qui se trouvent derrière eux. Si ces informations sont incomplètes, et dans la plupart des entreprises, certaines d’entre elles le sont généralement, alors l’automatisation peut devenir très efficace pour faire passer des décisions erronées à travers le système.

Le troisième risque est comportemental. Une fois que les gens commencent à faire confiance au flux de travail trop much, ils cessent d’interroger ses sorties. Les équipes supposent que ce qui émerge en haut doit être ce qui compte le plus et ce qui ne monte pas peut attendre. C’est compréhensible, mais je crois que c’est dangereux. Parce que cela déplace la culture de la gestion des risques éclairée à l’acceptation passive de l’ordre donné par la machine.

Et puis il y a un risque stratégique plus large, qui est que les organisations commencent à confondre le débit avec l’amélioration de la sécurité. Fermer un grand volume de vulnérabilités semble bon opérationnellement. Cela crée des tableaux de bord, des métriques et un sentiment d’élan. Mais si vous n’êtes pas en train de réduire les expositions qui comptent le plus pour l’entreprise, vous pouvez simplement devenir plus rapide à avoir l’air occupé.

Donc, mon point de vue est que l’automatisation devrait absolument faire le travail de force. Mais elle devrait soutenir le jugement, pas le remplacer. Sinon, vous finissez par avoir un processus qui est efficace, mesurable et évolutif, mais pas nécessairement plus sûr.

Vous avez travaillé étroitement dans la transformation TI et l’architecture d’entreprise. Comment les DSI devraient-ils équilibrer la nécessité de corriger rapidement les vulnérabilités par rapport aux risques opérationnels de perturbation des systèmes métier critiques ?

Excellente question, car c’est l’un de ces domaines où la réponse facile est généralement la mauvaise.

Bien sûr, vous voulez corriger rapidement. Aucun DSI ne va argumenter pour s’asseoir sur des vulnérabilités connues plus longtemps que nécessaire. Mais dans une véritable entreprise, en particulier celle qui exécute des systèmes critiques, la rapidité n’est pas l’objectif en soi. Si vous corrigez mal et que vous mettez hors service quelque chose dont l’entreprise dépend, vous avez résolu un problème en en créant un autre.

Donc, l’équilibre est vraiment une question de compréhension de quels risques sont réels, lesquels sont théoriques et quels systèmes peuvent tolérer le changement sans causer des ennuis ailleurs.

Certaines vulnérabilités nécessitent vraiment une action urgente. Si quelque chose est exposé, exploitable et se trouve dans une partie de l’environnement qui compte, alors vous agissez. Mais la plupart du temps, la décision est moins absolue que les gens le font paraître. Vous pouvez avoir d’autres contrôles autour du problème. Le système affecté peut être étroitement contenu. Le risque opérationnel de réaliser le changement aujourd’hui peut être plus élevé que de maintenir la position pendant une courte période et de le faire correctement.

C’est pourquoi les meilleurs DSI tendent à être ceux qui peuvent avoir une conversation adulte avec l’entreprise. Pas seulement : « C’est critique, corrigez-le maintenant », mais « Voici l’exposition, voici ce qui pourrait se produire, voici ce qui pourrait aller mal si nous intervenons mal et voici la façon la plus sûre de passer à travers ». C’est une forme plus crédible de leadership que de traiter chaque vulnérabilité comme si elle existait en isolation.

Je pense également que ces moments mettent en évidence quelque chose de plus profond sur l’environnement lui-même. Si une organisation a constamment peur de corriger les systèmes principaux parce que tout changement semble dangereux, cela indique généralement que l’environnement est devenu fragile. Trop de dépendances cachées, pas assez de confiance dans les tests, trop peu de résilience dans l’architecture. Dans cette situation, le débat sur la correction est vraiment un symptôme d’un problème plus ancien.

Donc, oui, corrigez rapidement lorsque le risque est réel et que le chemin est clair. Mais lorsque l’environnement est sensible, le travail consiste à réduire le risque sans créer un plus grand désordre. C’est l’équilibre.

Et pour être honnête, la plupart des DSI expérimentés le savent déjà. Le défi est d’appliquer leur décision sous pression, lorsque l’horloge tourne et que personne ne veut posséder les conséquences de se tromper.

L’approche de Spinnaker combine l’analyse basée sur l’IA avec une validation d’expert. Quelles tâches l’IA devrait-elle gérer, et quelles décisions devraient rester fermement entre les mains d’experts en sécurité expérimentés ?

Je pense que la ligne de démarcation est en fait assez simple.

L’IA devrait faire le travail qui bénéficie de la vitesse, de l’échelle et de la cohérence. Passer en revue de grandes quantités de données, rassembler des signaux, détecter des modèles, signaler les choses qui semblent hors norme, aider les équipes à réduire le champ, c’est exactement le type de travail pour lequel les machines sont utiles. Cela économise du temps, réduit l’effort manuel et donne aux équipes de sécurité un meilleur point de départ.

C’est également bien adapté aux parties répétitives du travail. Le premier niveau de tri. La synthèse des résultats. La connexion de problèmes similaires. Le suivi des exceptions répétées. Le signalement des endroits où certains types de faiblesses de contrôle continuent d’apparaître. Aucun de ces éléments ne remplace l’expertise, mais il en fait un meilleur usage.

Où je serais beaucoup plus prudent, c’est lorsque vous passez de l’analyse à la prise de décision.

Les appels importants devraient encore reposer sur des professionnels de la sécurité expérimentés. Est-ce vraiment un risque grave dans cet environnement commercial ou ne semble-t-il grave que dans l’abstrait ? Est-ce une véritable défaillance de contrôle ou est-ce une exception désordonnée mais comprise ? Si nous corrigeons cela maintenant, qu’est-ce que nous pourrions perturber ? Si nous attendons, qu’est-ce que nous acceptons vraiment ? Ce sont des appels de jugement.

Et c’est avant même de parler du côté humain. Pourquoi cela se produit-il continuellement ? L’organisation est-elle consciente de ce risque ou a-t-elle simplement cessé de le remarquer ? Est-ce un problème isolé ou un signe de quelque chose de culturel en dessous ? Ce type d’interprétation compte encore beaucoup.

Donc, je laisserais l’IA faire le tri, le regroupement, le premier passage, l’effort lourd. Mais je ne la laisserais pas décider ce que l’entreprise devrait se soucier le plus ou quelle action devrait être prise sans examen humain.

Parce que dès qu’une décision a des conséquences, soit opérationnelles, financières ou de réputation, vous n’êtes plus simplement en train de traiter des informations. Vous prenez une décision.

Et en matière de sécurité, je crois que cela devrait toujours être une personne avec une véritable intelligence.

Beaucoup d’organisations se concentrent encore fortement sur les comptes de vulnérabilités et les scores de gravité. Pourquoi pensez-vous que la gestion réelle de l’exposition nécessite une vision plus large qui inclut les contrôles compensatoires, les restrictions d’accès, l’architecture du système et le contexte commercial ?

Cela nécessite une vision plus large parce qu’un nombre seul ne vous dit pas grand-chose sur le montant de problèmes dans lesquels vous êtes vraiment.

Les scores de gravité ont leur place. Les comptes de vulnérabilités ont leur place. Ils aident à dimensionner le problème. Ils aident à organiser la liste d’attente. Mais ils ne sont pas la même chose que la compréhension de l’exposition, et c’est là que je pense que beaucoup d’organisations se trompent encore.

Une vulnérabilité peut sembler grave en théorie et être relativement bien contenue dans la pratique. Si l’accès au système est étroitement limité, si des contrôles compensatoires sont en place, si cela se trouve dans une partie de l’environnement qui est difficile à atteindre via des restrictions d’accès, alors la probabilité réelle que ce problème cause du tort peut être très différente de ce que le score brut suggère.

Et puis vous avez le cas inverse, qui est souvent le plus intéressant. Quelque chose de plus bas dans la liste peut se révéler importer beaucoup plus parce de où il se situe. Il touche un service critique. Il est plus facile d’y accéder. Il se trouve dans une partie de l’architecture du système où une faille donne de la marge de manœuvre. C’est le type de chose qu’un classement de gravité simple ne peut pas expliquer bien.

Donc, lorsque les gens parlent de gestion de l’exposition, pour moi, cela doit signifier plus que simplement trier les vulnérabilités par score et travailler sur la liste.

Vous devez savoir ce qui se trouve autour du problème. Quels contrôles sont déjà en place. Qui peut y accéder. Si le système est isolé ou connecté à quelque chose de plus important. Et si cela est exploité, ce qui se passe vraiment ensuite.

Autrement, vous finissez par gérer l’image du risque plutôt que le risque lui-même. Le tableau de bord s’améliore. Les numéros de ticket bougent. Le rapport paraît meilleur. Mais vous n’êtes pas nécessairement plus en sécurité.

Je pense que la raison pour laquelle cela se produit est que les nombres sont rassurants. Ils semblent objectifs. Ils donnent aux gens quelque chose de propre à présenter. Ils créent le sentiment que le problème a été réduit à quelque chose de mesurable et sous contrôle. Mais l’exposition réelle est généralement beaucoup plus désordonnée que cela.

Elle se trouve à l’intersection de la faille, des contrôles qui l’entourent, de l’architecture dans laquelle elle réside et de la conséquence commerciale si quelque chose va mal.

Donc, oui, utilisez les scores. Utilisez les comptes. Bien sûr. Mais ne les confondez pas avec la compréhension.

Si vous voulez savoir où se trouve la véritable exposition, je crois que vous devez regarder l’ensemble de l’environnement, et non juste un nombre attaché à celui-ci.

Les environnements de logiciels d’entreprise entrent dans une période de changement significatif à mesure que les organisations modernisent les systèmes hérités tout en adoptant simultanément les technologies d’IA. En regardant vers les trois à cinq prochaines années, comment voyez-vous l’évolution de la relation entre l’IA, la cybersécurité et les plates-formes d’entreprise, et à quoi les dirigeants technologiques devraient-ils se préparer aujourd’hui ?

Je pense que les trois à cinq prochaines années seront assez déterminantes.

Principalement parce que les entreprises tentent de moderniser les anciens environnements d’entreprise en même temps qu’elles introduisent l’IA dans le mélange, et que ni l’une ni l’autre de ces choses n’est facile à réaliser seule. Les faire ensemble augmente les enjeux.

Ce qui change en premier, je pense, c’est que l’IA cesse d’être un experiment et commence à faire partie de la façon dont l’entreprise fonctionne réellement. Elle apparaît dans les flux de travail, le support, le développement, les opérations de sécurité et l’administration de la plate-forme, non comme une nouveauté, mais comme partie intégrante de l’infrastructure.

Et une fois que cela se produit, la conversation sur la cybersécurité devient plus sérieuse. Vous n’êtes plus en train de demander si l’outil est utile. Vous demandez ce qu’il peut atteindre, ce qu’il peut influencer, quelles données il alimente et quelles sont les conséquences lorsqu’il se trompe.

Je pense également que nous allons voir la sécurité et l’architecture devenir encore plus difficiles à séparer. Dans de nombreux anciens environnements, la chose qui ressemble à un problème de sécurité est souvent en réalité un problème d’architecture portant un badge de sécurité. Conception d’identité faible, trop de dépendances, propriété non claire, intégrations fragiles, visibilité médiocre, ce sont les choses qui ont tendance à se cacher sous le problème visible. L’IA ne va pas lisser cela. Si quoi que ce soit, elle peut exposer le désordre plus rapidement.

Donc, les organisations qui gèrent cela bien, je crois, seront celles qui arrêtent de traiter l’adoption de l’IA, la cybersécurité et la modernisation de la plate-forme comme trois flux de travail distincts. Ce sont de plus en plus les mêmes conversations.

Si je conseillais les dirigeants technologiques maintenant, je commencerais par la visibilité. Vous avez besoin d’une poignée beaucoup plus claire sur ce que vous avez, comment cela se connecte, qui a accès à quoi, où les données sensibles se déplacent et où se trouvent vos véritables points de contrôle. Sans cela, ajouter l’IA en haut ne fait que augmenter le nombre de choses que vous ne comprenez pas vraiment.

La deuxième chose est la gouvernance, mais pas le type de gouvernance qui se contente de paraître bien. Des décisions réelles. Où peut-on utiliser l’IA ? Où le contrôle humain doit-il rester en place ? Comment les sorties sont-elles vérifiées ? Quelles données sont hors limites ? Qui possède les conséquences si le système conduit à une mauvaise action ? Ces questions doivent être résolues maintenant, et non plus tard.

Et honnêtement, la simplification compte plus que beaucoup de gens veulent l’admettre. Plus l’environnement est emmêlé, plus il est difficile à sécuriser, plus il est difficile à moderniser et plus il est difficile d’utiliser l’IA sans créer une incertitude nouvelle.

Ensuite, il y a le côté humain. Les meilleures organisations seront celles qui savent combiner l’automatisation avec le jugement. Elles n’accepteront pas la sortie de l’IA simplement parce qu’elle est rapide ou polie. Elles la remettront en question. La testeront. La contesteront lorsque nécessaire.

Donc, oui, au cours des prochaines années, je pense que l’IA, la cybersécurité et les plates-formes d’entreprise deviendront beaucoup plus étroitement liées.

Et je pense que les dirigeants qui se prépareront bien seront ceux qui comprendront que ce n’est pas seulement un changement technologique. C’est un changement dans la façon dont les décisions sont prises, dans la façon dont le contrôle est exercé et dans la façon dont l’organisation est vraiment résiliente.