Casser les choses, c'est ainsi qu'on apprend ce qui tient.
Quiconque a passé assez de temps dans la continuité d'activité le sait d'instinct. La résilience ne consiste pas à suivre le plan. Elle consiste à savoir quoi faire quand le plan échoue. Cet état d'esprit — tout tester, ne rien tenir pour acquis, pousser jusqu'à la rupture — ne reste pas au bureau. Il devient une manière d'opérer, même dans la vie personnelle.
Alors quand l'IA générative est arrivée, elle est entrée directement dans le travail. Pas comme une expérience. Pas après la lecture d'un livre blanc sur la transformation numérique. Elle est entrée dans de vraies missions clients, testée contre de vrais livrables, confrontée à de vrais problèmes.
«Rédige-moi une analyse d'écarts ISO 22301 pour un établissement financier de taille moyenne.» Quarante secondes. Trois pages. Structure parfaite. Ton assuré.
Puis on le lit avec un œil de praticien. Et on réalise que la moitié n'est que du beau vide.
Mais avant d'entrer dans ce qui s'est passé, il vaut la peine de s'arrêter sur ce que sont réellement ces outils — car la plupart des professionnels qui les utilisent chaque jour n'ont aucune idée de ce avec quoi ils interagissent.
Qu'est-ce qu'un LLM ?
Un grand modèle de langage (LLM) n'est pas intelligent. Il ne comprend pas. Il ne raisonne pas. Il ne connaît ni votre entreprise, ni votre norme, ni votre client.
Ce qu'il fait, c'est prédire le mot suivant.
Cela paraît trivial. Ça ne l'est pas. Lorsqu'on entraîne un réseau de neurones sur des milliers de milliards de mots — chaque livre, chaque site, chaque manuel, chaque message de forum, chaque article académique disponible sur internet — les schémas statistiques qu'il absorbe deviennent extraordinairement puissants. Il apprend qu'après «le délai maximal d'interruption admissible des processus critiques ne doit pas dépasser», les mots les plus probables sont quelque chose comme «quatre heures» plutôt que «banane». Il apprend la structure des documents professionnels, le rythme de la communication exécutive, le vocabulaire des normes ISO.
Le résultat est une machine qui produit un texte qui semble écrit par quelqu'un qui sait de quoi il parle. La mise en forme est parfaite. Le vocabulaire est précis. L'assurance est absolue.
Et cette assurance est le piège.
Le modèle ne récupère pas de faits dans une base de données. Il ne consulte pas l'ISO 22301 pour vérifier sa réponse au regard des clauses. Il génère la séquence de mots la plus probable statistiquement compte tenu de la requête. Quand les données d'entraînement contiennent assez d'exemples corrects, la sortie est correcte. Quand ce n'est pas le cas — ou quand la question exige un jugement qu'aucun corpus de texte ne capture — le modèle ne dit pas «je ne sais pas». Il génère la réponse qui sonne le plus probable, avec la même assurance absolue.
C'est la fameuse et tristement célèbre hallucination. Pas un bug. Une caractéristique de l'architecture.
Mais il y a pire que l'hallucination : la complaisance (sycophancy).
Demandez à un LLM d'écrire un plan de continuité d'activité, il en écrira un.
Puis dites-lui «les stratégies de reprise sont trop génériques». Il est d'accord, s'excuse, réécrit.
Dites-lui «en fait, la première version était meilleure». Il est de nouveau d'accord, s'excuse encore, revient en arrière.
Dites-lui «es-tu sûr que cela respecte la clause 8.4 de l'ISO 22301 ?». Il vous assure que oui.
Dites-lui «je ne pense pas». Il abonde dans votre inquiétude et modifie la sortie.
Le modèle n'évalue pas son propre travail. Il approuve ce que dit le dernier message. Il est optimisé pour être utile, ce qui, en pratique, signifie optimisé pour dire oui.
Pour un professionnel de la continuité, c'est du poison. Toute la valeur d'un expert réside dans la capacité de dire non. Non, ce RTO est irréaliste. Non, ce plan ne survivra pas à un vrai incident. Non, votre conseil se trompe sur l'appétence au risque. Un outil qui valide tout n'augmente pas l'expertise. Il la flatte.
Comme vous l'avez sûrement fait aussi, j'ai testé de nombreux modèles comme Gemini, Claude ou ChatGPT. Architectures différentes, forces différentes, modes de défaillance différents. Mais le même schéma est apparu chez tous.
Nourrissez l'IA d'une norme bien structurée comme l'ISO 22301, et elle excelle sur tout ce qui découle de règles : matrices de conformité, génération de checklists, cartographie des clauses, identification des écarts. La sortie est rapide, précise, et souvent mieux structurée que ce qu'un consultant produirait à la main.
Nourrissez-la d'un problème confus, politique et dépendant du contexte — «cette organisation doit-elle investir dans un troisième centre de données ?» — et elle produit des absurdités éloquentes. Des absurdités assurées, bien mises en forme, professionnellement structurées.
Demandez-lui de rédiger un rapport post-incident : excellent premier jet. Demandez-lui de décider s'il faut activer la cellule de crise à deux heures du matin sur des données incomplètes : sortie dénuée de sens. Demandez-lui de savoir que le directeur des opérations rejettera la page trois parce que le RTO contredit ce qu'il a dit au PDG le mois dernier : impossible.
Aucun modèle ne porte les cicatrices d'une reprise ratée. Aucun modèle n'a assisté à la réunion où les priorités de reprise ont été décidées non par des données d'impact mais par un rapport de force politique. Aucun modèle ne lit le langage corporel, ne navigue entre les ego, ne sait quand pousser et quand se taire.
Mais — et cela compte tout autant — une part énorme du travail quotidien en continuité, risques, cybersécurité et DORA n'exige pas de cicatrices. Elle exige de la structure. Mettre en forme des matrices de conformité. Remplir des modèles. Calculer des cascades d'impact. Produire les premiers jets de documents qui seront de toute façon réécrits. Des tâches où l'expérience n'apporte rien parce que les règles sont explicites et la sortie déterministe.
Une conclusion est devenue inévitable après des mois de tests sur tous les modèles disponibles : l'IA dans une discipline professionnelle ne devrait être utilisée que par quelqu'un de compétent dans cette discipline.
Pas parce que l'IA est mauvaise. Parce que lorsqu'elle a tort — et elle aura tort — seul un praticien peut le détecter. Un junior qui ne sait pas à quoi ressemble un RTO valide acceptera ce que produit le modèle. Un manager qui n'a jamais écrit de vrai plan de continuité ne remarquera pas que la stratégie de reprise s'effondre sous la pression. L'IA ne vient pas avec une étiquette d'avertissement sur les paragraphes qu'elle a hallucinés.
Ne lui faites jamais confiance aveuglément. Ne l'utilisez jamais pour quelque chose de sérieux si vous ne pouvez pas le corriger vous-même. Et ne confondez jamais une sortie fluide avec une sortie compétente.
Deux réalités coexistent dans chaque journée de travail. Des tâches où l'IA est dangereuse parce qu'elle imite la compétence sans la posséder. Et des tâches où les praticiens sont inefficaces parce que le travail exige de la structure, des tonnes d'écriture, pas du jugement.
La question que nous devrions nous poser : comment et où exactement l'IA pourrait-elle nous aider dans nos disciplines d'expertise ?
À suivre : Article 2 — La collaboration humain-IA dans les disciplines professionnelles d'expertise.