Vérification

Cela a-t-il fonctionné en dehors du laboratoire ?

Une technologie réussit son pilote. Les résultats sont bons, le rapport est positif, la certification est en ordre. Elle est achetée et déployée.

Puis elle rencontre des conditions que personne n’a testées. Des opérateurs sous pression au lieu d’une équipe projet engagée. Une intégration avec des systèmes qui n’étaient jamais présents dans le pilote. Une alimentation dégradée, une mauvaise connectivité, des interférences, le froid, la poussière, la charge. Un adversaire qui se comporte différemment du scénario de test. En quelques mois, la capacité qui fonctionnait dans le pilote est contournée dans les opérations.

La plupart des personnes concernées ont correctement fait leur travail. Le pilote a montré ce qu’il était conçu pour montrer. Le problème est qu’on lui a fait montrer autre chose : que la capacité fonctionne là où elle est nécessaire.

C’est le problème que nous désignons par vérification. Des capacités sont régulièrement déployées sur la base de preuves recueillies ailleurs, dans d’autres conditions, souvent par quelqu’un qui a un intérêt dans le résultat. Tant qu’une capacité n’a pas été démontrée là où elle est nécessaire, son déploiement repose sur une hypothèse.

Notre position est simple. Validé ne signifie pas déployé. La preuve est une propriété d’une capacité dans des conditions déclarées, et elle n’est jamais plus forte que les conditions dans lesquelles elle a été recueillie.

Un pilote réussi prouve le pilote

Les pilotes sont conçus pour réussir. Ce n’est pas du cynisme ; c’est leur mode d’organisation. Le périmètre est limité, l’équipe est motivée, le fournisseur est étroitement impliqué, l’environnement est préparé et les problèmes sont corrigés au fur et à mesure.

Tout cela fait du pilote un bon test pour savoir si quelque chose peut fonctionner. Cela en fait un mauvais test pour savoir si cela fonctionnera lorsque le fournisseur prendra du recul, que l’équipe d’origine passera à autre chose et que la capacité devra fonctionner dans les opérations ordinaires.

L’écart entre les deux est bien connu. Dans la politique d’innovation, on l’appelle souvent la « vallée de la mort » : la distance entre un résultat prometteur et une capacité déployée, où beaucoup d’initiatives s’arrêtent. La réponse habituelle consiste à financer davantage de pilotes. Cela produit davantage de résultats prometteurs, et la même vallée.

Ce qui manque est rarement un autre pilote. C’est une manière de recueillir des preuves dans les conditions que la capacité rencontrera réellement.

Vérification et validation répondent à des questions différentes

L’ingénierie des systèmes distingue depuis longtemps deux questions qu’il est facile de confondre.

La vérification demande si le système a été correctement construit : fait-il ce que sa spécification dit ? La validation demande si le bon système a été construit : fait-il ce dont ses utilisateurs ont réellement besoin, dans l’environnement où ils en ont besoin ? Des normes telles qu’IEEE 1012 traitent ces deux activités séparément pour de bonnes raisons.

Une capacité peut réussir la vérification et échouer à la validation. Elle satisfait toutes les exigences sur le papier et ne fonctionne pourtant pas pour les personnes et les conditions pour lesquelles elle a été achetée, parce que les exigences elles-mêmes ont été écrites pour un monde plus propre.

Nous employons « vérification » au sens large dans lequel les personnes extérieures à l’ingénierie l’emploient : établir, avec des preuves, qu’une capacité fonctionne là où elle est censée fonctionner. Cela inclut les deux questions. Ne répondre qu’à la première est la manière dont des systèmes finissent certifiés et inutilisés.

Les niveaux de maturité mesurent la maturité, pas l’adéquation

Les Technology Readiness Levels constituent un langage commun utile. Ils décrivent le chemin parcouru par une technologie, depuis les principes de base jusqu’à un système démontré dans son environnement opérationnel. Les programmes européens de recherche les utilisent pour décrire le point de départ et le point d’arrivée attendu d’un projet.

Ils sont également faciles à surinterpréter. Un niveau de maturité indique à quel point une technologie a progressé sur un chemin général. Il ne dit pas si elle convient aux conditions, aux systèmes et aux personnes d’une institution particulière. Un système démontré dans « un environnement opérationnel » l’a été dans un environnement opérationnel quelconque, pas nécessairement le vôtre.

Nous traitons donc un niveau de maturité comme le début d’une conversation sur les preuves, pas comme sa conclusion. La question suivante est toujours la même : démontré où, dans quelles conditions, et à quel point celles-ci sont-elles proches des nôtres ?

L’environnement fait partie du test

L’endroit où une capacité est testée détermine ce que le test peut montrer. Un laboratoire peut établir des performances dans des conditions contrôlées. Il ne peut pas établir le comportement dans les conditions qui rendent les opérations réelles difficiles.

Des environnements différents exposent des types de défaillance différents. Un cadre isolé ou durci teste ce qui se passe lorsque le support, la connectivité et l’approvisionnement sont coupés. Un environnement maritime réel teste l’exposition aux intempéries, à la corrosion, à la distance et à la difficulté d’accès physique. Un cadre qui franchit une frontière administrative ou nationale teste si l’autorité, les procédures et les transferts fonctionnent lorsqu’ils doivent fonctionner. Un bureau ordinaire ou un environnement de test cloud ne teste rien de cela.

C’est pourquoi nous traitons l’environnement de test comme un instrument à part entière. Le choisir est une décision de conception : il détermine quelles conditions de défaillance peuvent être exercées et, par conséquent, quelles affirmations le résultat peut soutenir.

Tout résultat a des conditions

Un résultat de test qui n’indique pas ses conditions invite à être généralisé au-delà de celles-ci.

Pour tout résultat de vérification, nous voulons au minimum savoir : ce qui a été testé, dans quelle configuration, dans quel environnement, par qui, dans quelles conditions, pendant combien de temps, ce qui a été mesuré, ce qui s’est produit et ce qui a délibérément été laissé de côté. Le dernier élément est celui qui manque le plus souvent et celui qui compte le plus pour le prochain acheteur.

Un résultat étroit qui énonce ses limites est utile. On peut s’y fier, le comparer et construire dessus. Une affirmation large sans conditions ne peut qu’être crue ou rejetée.

C’est la même discipline qui s’applique aux affirmations de résilience. Un résultat dans une enveloppe ne prouve rien en dehors d’elle. Voir Résilience.

Les résultats négatifs sont des preuves

Les tests qui échouent nous apprennent au moins autant que ceux qui réussissent. Ils montrent où se trouvent réellement les limites d’une capacité, quelles conditions elle ne peut pas supporter et quelles hypothèses de sa conception n’ont pas tenu.

Ce sont aussi les résultats les plus susceptibles de disparaître. Les fournisseurs ont peu de raisons de les publier. Les acheteurs peuvent ne pas vouloir reconnaître un achat raté. Les programmes sont jugés sur leurs réussites.

Nous considérons l’échec documenté comme faisant partie de la base de preuves. Un dossier de vérification qui ne contient que des réussites décrit soit une capacité qui n’a jamais été poussée jusqu’à ses limites, soit un dossier auquel il manque quelque chose.

L’acheteur doit pouvoir juger

La plupart des preuves de vérification arrivent à une institution par l’intermédiaire de quelqu’un qui a un intérêt dans le résultat : un rapport de test du fournisseur, une certification obtenue par le vendeur, une référence d’un autre client. Aucun de ces éléments n’est sans valeur. Aucun n’est indépendant.

Une institution incapable de lire de manière critique de telles preuves ne peut pas distinguer une affirmation solide d’une affirmation bien présentée. Elle ne peut pas demander quelles conditions ont été testées, si elles correspondent aux siennes ou ce qui a été laissé de côté. Elle achète l’étiquette.

C’est ici que la vérification dépend du jugement. L’acheteur a besoin de personnes capables d’évaluer des preuves produites par d’autres et de demander celles qui trancheraient réellement la question. Cette capacité doit exister dans l’institution, pas seulement chez ses conseillers. Voir Transfert de capacité.

Du pilote à l’infrastructure

Le point d’arrivée de la vérification n’est pas un rapport. C’est une capacité que l’institution exploite, dans ses propres conditions, avec des preuves qu’elle fonctionne là.

Beaucoup d’initiatives s’arrêtent au pilote parce que le financement s’arrête. Il en résulte une démonstration que personne n’exploite. Nous traitons le pilote comme une étape d’une séquence plus longue : tester dans des conditions contrôlées, puis dans les conditions qui comptent, puis en exploitation par les personnes qui géreront la capacité, tout en enregistrant les preuves à chaque étape.

C’est la discipline Operations dans La séquence : mise en œuvre, testée dans des conditions réelles et transformée en quelque chose qui fonctionne de manière indépendante et durable après la fin de l’initiative qui l’a créée.

Comment nous travaillons ensemble

Notre travail sur la vérification avec un partenaire commence par les conditions auxquelles la capacité sera confrontée, pas par la capacité elle-même.

Nommer les conditions opérationnelles. S’accorder sur l’endroit et la manière dont la capacité sera réellement utilisée, y compris les conditions que personne n’aime planifier.

Lire les preuves existantes. Établir ce qui a été démontré, où, dans quelles conditions et ce qui a été laissé de côté.

Concevoir le test autour de l’écart. Choisir un environnement et des scénarios qui exercent les conditions que les preuves existantes ne couvrent pas.

Consigner le résultat avec ses conditions. Y compris ce qui a échoué et ce qui n’a pas été testé.

Laisser la capacité de juger. L’institution devrait terminer avec des personnes capables d’évaluer seules la prochaine affirmation d’un fournisseur, le prochain rapport de test ou la prochaine certification.

Lorsque nous examinons une capacité avec un partenaire, voici les questions que nous parcourons généralement :

Là où nous sommes prudents

Nous nous imposons quelques engagements quant à ce que nous affirmons.

Nous ne généralisons pas un résultat au-delà des conditions dans lesquelles il a été obtenu.

Nous ne traitons pas un niveau de maturité, une certification ou un rapport fournisseur comme une preuve qu’une capacité fonctionne dans un environnement particulier.

Nous ne présentons pas les environnements de test comme des résultats. Un environnement permet d’obtenir des preuves plus fortes ; il n’est pas lui-même une preuve.

Nous n’excluons pas les échecs du dossier.

Et nous ne décrivons pas une capacité comme démontrée sans préciser où, dans quelles conditions et par qui.

Lectures complémentaires

• Commission européenne, Horizon Europe General Annexes, définitions des Technology Readiness Levels.
• IEEE 1012, Standard for System, Software, and Hardware Verification and Validation.

Thèmes associés : Résilience · Transfert de capacité · Alerte précoce

Évolution de cette position

• 24 septembre 2026 — Première publication.

Les modifications substantielles sont indiquées ici avec leur date. Les corrections de formulation ou de liens ne le sont pas.