La méthode des preuves pour distinguer progrès et communication

La méthode des preuves pour distinguer progrès et communication

Quand le vert du tableau de bord ne remet pas l’activité en marche

Situation illustrative : un lundi matin, le comité de direction apprend que l’incident du week-end est « résolu ». Le serveur de flux répond, l’ERP est accessible et le prestataire a fermé son ticket. Pourtant, l’atelier ne reçoit toujours pas certaines nomenclatures, des commandes restent bloquées et la facturation attend les retours de consommation. Le DSI doit choisir : annoncer le rétablissement, prolonger la crise ou suspendre un processus commercial. Il doit déterminer ce qui est réellement revenu, sur quel périmètre et avec quel risque résiduel.

Dans cette situation, la communication produit vite des verbes rassurants : corrigé, sécurisé, stabilisé. La preuve oblige à formuler autre chose : composant redémarré, scénario testé, résultat observé, limite connue, responsable de validation identifié. Cette différence change la décision. Un service n’est pas repris parce qu’un équipement répond ; il l’est lorsque le parcours utile au métier fonctionne de bout en bout selon des critères convenus.

Pourquoi l’avancement déclaré résiste mal aux faits

Un programme ERP, une remédiation cyber ou un plan de stabilisation agrège des acteurs qui ne mesurent pas le même objet. L’intégrateur suit ses livrables, l’exploitation ses alertes, le RSSI ses vulnérabilités, le métier ses opérations et la direction ses engagements. Chacun peut donc annoncer un progrès sincère tout en décrivant une réalité partielle. L’illusion apparaît lorsque ces lectures sont additionnées sans être reliées.

Le mécanisme est classique : le statut d’une action remplace le résultat attendu. « Test terminé » ne dit pas si les anomalies bloquantes sont levées. « Correctif déployé » ne prouve ni son efficacité ni l’absence de régression. « Risque accepté » ne précise pas par qui, jusqu’à quand ni avec quelle compensation. Sous pression, le reporting privilégie une couleur simple. Le dirigeant doit refuser cet indicateur s’il ne permet aucune décision.

Construire un dossier de preuves utilisable

La méthode commence par une question : quelle décision cette information doit-elle éclairer ? Maintenir une bascule, rouvrir un service, payer un jalon ou accepter une exposition n’exige pas les mêmes pièces. Pour chaque décision, le DSI ou le RSSI définit l’objet observé, le résultat attendu, le valideur et la fraîcheur nécessaire.

Il constitue ensuite un registre commun. Chaque entrée relie un constat à sa source, son périmètre, sa version et ses limites. Une capture isolée peut confirmer un état à un instant donné ; elle ne démontre pas la continuité. Un procès-verbal de test atteste le scénario exécuté ; il ne couvre pas les branches absentes. Une estimation de charge éclaire un choix ; elle ne devient pas un engagement sans hypothèses explicites. Les inconnues restent inscrites au lieu d’être maquillées en absence de problème.

Enfin, les acteurs confrontent les pièces. Le métier valide la reprise d’activité, l’architecte relie applications et flux, l’exploitation confirme la tenue, le fournisseur décrit son intervention, le RSSI qualifie l’exposition restante. Le dossier rend visibles les désaccords et leur effet sur la décision.

Mesurer un progrès qui mérite ce nom

Les indicateurs doivent suivre la chaîne causale, pas l’agitation des équipes. Pour un service : composants disponibles, parcours métier rejoués, transactions en attente, reprises manuelles et incidents récurrents. Pour un programme : exigences démontrées, défauts bloquants, décisions de conception non closes, capacité absorbée par les reprises et dépendances sans propriétaire.

En cybersécurité, compter les vulnérabilités fermées ne suffit pas. Il faut connaître les actifs réellement couverts, la vérification du correctif, les exceptions, leur échéance et la capacité de détection pendant la période résiduelle. Aucun chiffre n’est pertinent sans dénominateur, périmètre et date. Le bon indicateur ne prouve pas que tout va bien ; il indique ce qui a changé et ce qui interdit encore de conclure.

Organiser la contradiction sans paralyser l’action

La preuve a un coût de collecte, de qualification et de revue. Tout démontrer ralentirait l’exploitation ; accepter la parole du dernier intervenant transformerait la vitesse en pari. Il faut proportionner l’exigence à la réversibilité et à l’impact métier.

Une action réversible peut reposer sur un contrôle léger. Une bascule ERP, un accès sensible ou un risque majeur demande une validation robuste. Le dirigeant fixe les seuils : décideur, preuves minimales, écarts imposant une escalade et conditions de retour arrière. La revue devient un lieu d’arbitrage, non un tribunal documentaire.

Éviter les faux dossiers de preuves

La première erreur consiste à accumuler des fichiers sans les rattacher à une décision. La seconde est de confondre absence de pièce et absence de fait : un coût non retrouvé n’est pas un coût nul ; un test non documenté n’est ni réussi ni forcément inexistant. La troisième est d’accepter des preuves produites sur une version différente de celle qui sera mise en service.

Autre dérive : laisser le fournisseur produire, interpréter et valider son résultat. Sa contribution est indispensable, mais la validation revient au responsable client et au métier. Réécrire l’historique détruit aussi le registre : une preuve corrigée doit conserver sa version antérieure, la cause du changement et son auteur.

Arbitrer sur le risque résiduel, pas sur le récit

À l’heure de décider, le DSI peut rencontrer trois états. Les preuves confirment le résultat : il engage l’étape suivante. Elles révèlent un écart maîtrisable : il avance avec une réserve datée, un responsable et une mesure compensatoire. Elles restent insuffisantes sur un point critique : il reporte, réduit le périmètre ou déclenche une vérification ciblée. Ce troisième choix n’est pas un aveu d’impuissance ; c’est le refus d’engager l’entreprise sur une affirmation invérifiable.

Cette discipline rejoint l’approche de DSI EN CRISE : protéger l’activité, établir un diagnostic fiable, clarifier les responsabilités et reprendre la maîtrise des fournisseurs comme des grands programmes. Elle ne promet pas la certitude. Elle permet mieux : distinguer ce qui est établi, ce qui reste probable et ce qui demeure inconnu. Un dirigeant IT crédible ne communique donc pas moins. Il communique à partir d’un état démontrable, nomme les limites et transforme chaque constat en décision explicite.

Pour approfondir

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Consulter la référence

Consulter la référence

#ManagementDeTransition #DSI #DirectionDeTransition #GuyDeLussigny #TransformationNumerique