Revue technique annuelle : ce que le comité stratégique doit demander

Une fois par an, le comité stratégique d’une PME examine les comptes, le carnet de commandes, les recrutements, parfois un projet d’acquisition. Le système d’information, lui, n’apparaît souvent qu’au détour d’une ligne de budget : « hébergement et maintenance, en légère hausse ».

C’est une lacune de gouvernance. L’application qui gère vos commandes, le serveur qui héberge vos données clients, le prestataire qui seul connaît le code : ce sont des actifs et des risques au même titre qu’un contrat client majeur. Et contrairement à ce dernier, ils se dégradent sans bruit, jusqu’au jour où ils cèdent.

Nous avons expliqué quand un comité stratégique est utile dans une PME. Voici ce qu’il devrait demander, une fois par an, sur le volet technique.

Le principe : des faits, pas des impressions#

Une revue technique n’est pas un exposé du responsable informatique sur les projets de l’année. C’est un contrôle, et il repose sur des questions dont la réponse est un fait vérifiable : une date, un nom, un document, un chiffre.

« Les sauvegardes sont en place » n’est pas une réponse. « La dernière restauration complète a été testée le 14 mars, elle a pris quatre heures » en est une.

Cette exigence de précision est la seule compétence requise. Un administrateur sans formation technique peut parfaitement mener la revue, à condition de refuser les réponses vagues.

Les huit questions#

1. Où en est la dette technique ? Quelles parties du système coûtent de plus en plus cher à faire évoluer, et la situation s’est-elle améliorée ou dégradée depuis l’an dernier ? On ne demande pas un inventaire exhaustif : on demande les trois zones les plus préoccupantes et leur tendance.

2. Qui a accès à quoi ? Combien de comptes disposent des droits d’administration sur les outils critiques ? Les comptes des personnes parties ont-ils été supprimés ? La double authentification est-elle activée sur la messagerie, l’hébergement et le nom de domaine ? C’est la question de sécurité la plus simple et la plus révélatrice.

3. Qu’avons-nous appris des incidents de l’année ? Pannes, intrusions, tentatives d’hameçonnage réussies, pertes de données. Un comité qui n’entend jamais parler d’incident ne doit pas en conclure qu’il n’y en a pas eu, mais qu’ils ne remontent pas.

4. De qui dépendons-nous ? Si la personne qui connaît le mieux le système partait demain, combien de temps faudrait-il pour reprendre la main ? Même question pour le prestataire principal. Une dépendance n’est pas un problème en soi : une dépendance que personne n’a mesurée, si.

5. Combien coûte notre infrastructure, et pourquoi ? L’évolution des coûts d’hébergement, de licences et d’abonnements sur trois ans, rapportée à l’activité. Une hausse peut être saine si l’activité suit ; elle devient un signal quand elle progresse seule.

6. Quand avons-nous restauré une sauvegarde pour la dernière fois ? Pas « avons-nous des sauvegardes », mais quand en a-t-on reconstruit une, en combien de temps, et avec quel résultat. C’est la seule réponse qui dit si l’entreprise survivrait à un rançongiciel.

7. Sommes-nous propriétaires de notre code ? En droit français, la cession des droits d’auteur doit être écrite et détaillée, droit par droit : c’est ce que prévoit l’article L131-3 du code de la propriété intellectuelle. Un logiciel développé par un prestataire sans clause de cession appropriée ne vous appartient pas pleinement. Nous détaillons ce point dans notre article sur la propriété du code et les contrats de prestation. La revue annuelle vérifie que chaque développement de l’année est couvert, et que le code source est effectivement détenu par l’entreprise, pas seulement accessible.

8. Quelles obligations nous concernent, et les tenons-nous ? Protection des données personnelles, exigences de sécurité imposées par vos clients, obligations sectorielles. Beaucoup de PME découvrent qu’elles sont concernées par la directive NIS2 non pas directement, mais par l’intermédiaire de leurs clients : nous expliquons ce mécanisme dans notre article sur NIS2 et la sous-traitance.

Le rapport d’une page#

Ces huit questions ne doivent pas produire un document de quarante pages que personne ne lira. Le format qui fonctionne tient sur une seule page, envoyée avec l’ordre du jour, et suit la même structure chaque année pour que les évolutions sautent aux yeux.

L’exemple ci-dessus est fictif, mais sa forme est la bonne : trois couleurs, une tendance, un fait, une décision. Le comité ne débat pas des lignes vertes. Il consacre son temps aux lignes rouges et orange, et repart avec des décisions datées et un responsable pour chacune.

Qui prépare, qui challenge#

Le rapport est préparé par le responsable technique de l’entreprise s’il existe, à défaut par le prestataire principal. C’est là que se niche la difficulté : on demande à celui qui gère le système de s’évaluer lui-même.

Il faut donc un regard extérieur, au moins sur les lignes sensibles. Il peut venir d’un administrateur à compétence technique siégeant au comité, d’un directeur technique à temps partagé, ou d’un audit ponctuel lorsque le rapport révèle une zone d’ombre. L’enjeu n’est pas la défiance : c’est d’éviter qu’un risque reste invisible simplement parce que personne n’avait intérêt à le signaler.

C’est précisément le rôle que nous tenons dans nos missions de board member technique : poser ces questions chaque année, lire les réponses avec un œil d’ingénieur, et aider le comité à décider sans devenir lui-même un comité technique.

Commencer cette année#

Si votre comité n’a jamais fait cet exercice, la première revue sera imparfaite. Plusieurs questions resteront sans réponse précise, et c’est en soi une information précieuse : une question à laquelle personne ne sait répondre est un risque que personne ne pilote.

Inscrivez le point à l’ordre du jour de la prochaine séance, transmettez les huit questions à la personne qui préparera le rapport, et donnez-lui un mois. L’année suivante, la colonne « tendance » prendra tout son sens.