Un équipementier de taille intermédiaire, une gamme de passerelles industrielles vendue dans toute l’Europe. Le dossier CRA est prêt : analyse d’écart, nomenclature logicielle, politique de divulgation coordonnée. Tout est écrit, relu, validé.
Rien n’a jamais été branché. Le produit arrive sur le banc un lundi matin. À midi, nous avons trois écarts entre ce que le dossier annonce et ce que la carte contient.
Le problème
Le premier écart est structurel. Le dossier décrit le produit conçu, le banc montre celui qui a été fabriqué. Port de debug ouvert, bibliothèque plus ancienne que la nomenclature : les deux peuvent diverger, parfois suffisamment pour remettre en cause les hypothèses du dossier.
Le deuxième tient à la méthode. La R&D teste la fonction : elle vérifie que le produit marche. Un banc teste l’abus : ce qui arrive quand on s’en sert autrement. Ce n’est pas le même travail.
Le troisième est commercial. Une déclaration affirme la conformité. Un rapport de test documente les vérifications qui permettent de la défendre. Le jour où un donneur d’ordre demande la preuve, l’écart se paie en semaines de retard sur une commande.
La décision clé
Passer le produit sur un banc avant de signer la déclaration de conformité, et non après la première question d’un client.
En pratique
1. Tester le produit avec son écosystème
Un équipement seul ne se teste pas utilement. Il faut le banc complet : l’application de configuration, le portail cloud s’il existe, le canal de mise à jour, les identifiants d’usine. C’est là que se trouvent la plupart des écarts, parce que ces composants sont développés par des équipes différentes, parfois par un prestataire, et rarement audités ensemble.
2. Reproduire l’usage réel, pas les conditions de laboratoire
Un produit installé chez un client est mal configuré, jamais mis à jour, branché sur un réseau à plat et administré par un technicien pressé. Le banc doit refléter cet état, pas la configuration nominale du manuel. Les vulnérabilités qui comptent sont celles qui restent exploitables dans la configuration que vos clients utilisent vraiment.
3. Attaquer toutes les interfaces, y compris celles qu’on a oubliées
Le réseau et le web sont les plus regardés parce qu’ils sont les plus accessibles. Les interfaces série, USB, JTAG et radio le sont beaucoup moins, et ce sont elles qui donnent l’accès au firmware. Un attaquant qui achète votre produit d’occasion ne se limite pas au port Ethernet.
4. Vérifier la chaîne de mise à jour de bout en bout
C’est l’un des points structurants du CRA, et c’est le point le plus souvent négligé. Signature vérifiée sur l’équipement, canal protégé, protection contre le retour vers une version connue comme vulnérable lorsque le niveau de risque le justifie, comportement en cas d’échec. Un produit qu’on ne peut pas corriger sur le terrain n’est pas supportable dix ans.
5. Produire un rapport qui serve à deux publics
La R&D a besoin de reproductibilité : configuration exacte, étapes, correctif proposé. La direction et les clients ont besoin d’une preuve datée, traçable et exploitable en audit ou en appel d’offres. Un seul document ne sert bien qu’un des deux. Le rapport se rédige en deux parties dès le départ — c’est ce qui évite de le réécrire au moment de l’appel d’offres.
Recommandations
Passer sur le banc avant le gel du design. Un écart trouvé en conception coûte une décision. Le même écart trouvé après la mise en série coûte un rappel, ou un contournement documenté qu’on traînera dix ans.
Ne pas confondre banc produit et test d’intrusion applicatif. Les compétences, l’outillage et les livrables diffèrent. Un pentest sur votre portail client ne dit rien de la sécurité de l’équipement lui-même.
Faire du rapport un argument de vente. Vos clients industriels vont l’exiger. Ceux qui peuvent le produire en trois jours gagnent les appels d’offres que les autres passent trois mois à instruire.
Conclusion
Un dossier de conformité se construit à partir de faits mesurés ou à partir de déclarations. Les deux se ressemblent sur le papier, jusqu’au premier audit. La différence tient à une semaine de banc, en amont, à un moment où corriger coûte encore peu.
Vous voulez voir ce que donne votre produit sur un banc ?
Nous testons gratuitement un produit de votre gamme sur notre banc d’essai cybersécurité et vous remettons le rapport complet. Sans engagement.