Comment lire nos affirmations

Ce que nous pensons, ce que nous avons construit et ce que nous avons l’intention de faire sont trois choses différentes.

Les organisations qui décrivent leur propre travail ont tendance à brouiller trois types d’énoncés : ce qu’elles croient, ce qu’elles ont fait et ce qu’elles prévoient de faire. Lus rapidement, les trois peuvent ressembler à des réalisations.

Nous essayons de les garder séparés, car un partenaire qui décide s’il veut travailler avec nous devrait pouvoir distinguer les uns des autres. Cette page explique comment.

Trois types d’énoncés

Position. Notre manière de penser un problème. Les pages thématiques de ce site — Souveraineté, Résilience, Alerte précoce, Vérification, Transfert de capacité et Préparation à l’IA — sont des positions. Elles exposent les distinctions que nous trouvons utiles, les erreurs que nous voyons se répéter et les engagements que nous prenons quant à nos propres affirmations. Une position peut être contestée. Ce n’est pas l’affirmation que quelque chose a été construit ou démontré.

Construit. Quelque chose qui existe et peut être inspecté. Lorsque nous disons que nous avons construit quelque chose, cela est en fonctionnement et il existe un moyen de le vérifier. Machine Page Format (MPF) en est un exemple : la spécification est publiée, l’implémentation de référence existe et ce site est publié avec elle. N’importe qui peut récupérer la sortie et la comparer à la spécification.

Intention. Quelque chose que nous prévoyons ou que nous avons conçu, mais qui n’est pas encore construit ou démontré. Nous le décrivons comme une intention, pas comme une réalisation. La conception est une véritable étape du travail et possède une véritable valeur. Elle n’est pas la même chose qu’un système qui fonctionne, et nous n’en parlons pas comme si elle l’était.

Lorsqu’une page mélange ces catégories, elle le dit. Lorsqu’elle ne le précise pas, la règle par défaut est que les pages thématiques sont des positions et que les pages de normes décrivent ce qui est construit.

Une déclaration n’est pas une preuve

Une grande partie de ce dont dépendent les institutions est déclarée plutôt que démontrée : la déclaration d’un fournisseur sur l’endroit où les données sont traitées, un certificat, un rapport de test, un champ de métadonnées. Les déclarations sont utiles. Elles ne sont pas la même chose qu’une preuve que quelque chose est vrai.

Nous appliquons la même distinction à nous-mêmes. Lorsque nous formulons une affirmation sur notre propre travail, nous essayons d’indiquer sur quoi elle repose : si elle peut être inspectée, si elle a été testée et dans quelles conditions, ou s’il s’agit de notre propre évaluation.

« Inconnu » est une réponse acceptable

Lorsque nous ne savons pas quelque chose, nous le disons. Nous préférons laisser une question ouverte plutôt que la remplir par une hypothèse qui ressemble à une constatation.

Cela vaut autant pour nos évaluations avec des partenaires que pour ce que nous publions. Un « inconnu » honnête indique à un décideur où regarder ensuite. Une conjecture exprimée avec assurance ne lui apprend rien et peut l’envoyer dans la mauvaise direction.

Des affirmations étroites qui tiennent

Nous préférons une affirmation étroite et reproductible à une affirmation large qui ne l’est pas. « Cette fonction a continué pendant quatre heures avec un service réduit lorsque cette route a été perdue » est moins impressionnant que « résilient ». C’est aussi quelque chose qu’un partenaire peut vérifier, utiliser et approfondir.

Lorsqu’un résultat ne tient que dans des conditions particulières, nous indiquons les conditions. Lorsque nous généralisons, nous disons que nous généralisons.

Ce que vous ne trouverez pas ici

Nous ne décrivons du travail sur ce site qu’une fois qu’il est lancé publiquement. Vous n’y trouverez ni initiatives, ni formats, ni services avant ce point, quel que soit leur degré d’avancement dans la conception. Vous n’y trouverez pas non plus de partenariats suggérés par la simple mention du nom d’une institution. Et vous n’y trouverez pas de capacités attribuées à notre travail que celui-ci ne possède pas encore.

La même règle s’applique à companion.esfi.eu. Le Shipyard sur esfi.eu nomme les initiatives que nous développons ; chacune est documentée ici une fois lancée.

C’est un choix délibéré sur la fonction de la documentation. Sa valeur dépend de la capacité du lecteur à faire confiance au fait que ce qu’elle décrit est bien ce qu’elle dit être.

Lorsque notre point de vue change

Les positions évoluent. Les preuves changent, et notre compréhension avec elles. Lorsque nous modifions substantiellement une position, nous mettons la page à jour et indiquons ce qui a changé, plutôt que de remplacer silencieusement un point de vue par un autre.

Chaque page thématique porte à son pied un court historique des modifications : la date de première publication de la position et, pour chaque modification substantielle, la date et ce qui a changé. Les corrections de formulation ou de liens n’y sont pas listées ; les changements de fond le sont.

Les spécifications publiées suivent une règle plus stricte : lorsqu’une version est publiée, elle reste disponible sans être remplacée, et les changements apparaissent sous forme de nouvelles versions. Voir Versionnement.

Pourquoi cela compte pour nous

Le travail que nous faisons demande aux partenaires de juger les affirmations avec davantage de soin : affirmations sur le contrôle, sur la résilience, sur ce qu’une machine lit, sur la capacité qui reste. Nous ne pouvons pas le demander aux autres sans commencer par nous l’appliquer.

Associé : Six questions que nous posons · Glossaire · Versionnement