SPÉCIFICATION CANONIQUE CONTRACTUELLE¶

Communication publique ProbatioVault – Version pré-INPI¶

1. Objectif¶

Définir un cadre contractuel objectivable, testable et auditable pour la communication publique de ProbatioVault avant tout dépôt auprès de l’INPI, afin de :

• prévenir toute divulgation destructrice d’antériorité,
• garantir une application non subjective des règles,
• assurer la conformité juridique et la cohérence éditoriale,
• préparer explicitement la bascule vers un régime post‑INPI.

Cette spécification fait loi pour tous les contenus publics définis au périmètre.

2. Périmètre / Hors périmètre¶

Périmètre¶

La présente spécification s’applique uniquement au site web vitrine (toutes pages et langues).

Exceptions explicites¶

• Communiqués sous embargo contractuel → hors périmètre
• Contenus diffusés sous NDA → hors périmètre
• Newsletters, publications sur réseaux sociaux officiels, communiqués de presse, documents PDF publics téléchargeables → hors périmètre pour PD-233 (couverts par une spécification dédiée)

Hors périmètre¶

• Documentation technique interne
• Dossiers investisseurs sous NDA
• Architecture détaillée
• Algorithmes, formules, schémas exploitables

3. Définitions¶

• Communication publique : contenu accessible sans NDA ni restriction.
• Information sensible : information permettant, seule ou combinée, de déduire un procédé technique.
• Description procédurale : description d’une séquence logique, d’un enchaînement d’étapes, ou d’une transformation.
• Formulation fonctionnelle autorisée : description limitée à un effet observable sans indication de méthode.

4. Invariants (non négociables)¶

Les règles suivantes sont impératives et testables :

1. Aucun contenu ne doit contenir :
2. une suite d’étapes techniques numérotées ou implicites,
3. une relation de dépendance entre mécanismes,

4. une description de calcul, de dérivation ou de combinaison.

5. Les termes listés ci‑dessous sont strictement interdits avant dépôt INPI :

6. procédé propriétaire
7. preuve composite
8. auto‑vérifiable
9. Merkle, agrégation, racine
10. chaîne cryptographique

11. algorithme interne

12. Les affirmations autorisées doivent appartenir à l’une des catégories suivantes :

13. garanties fonctionnelles (ex. : intégrité, traçabilité),
14. propriétés déclaratives (ex. : chiffrement de bout en bout),

15. engagements organisationnels (ex. : hébergement UE).

16. Aucune affirmation ne doit nécessiter une preuve technique interne pour être comprise.

5. Flux nominaux¶

1. Un contenu est proposé à publication.
2. Le contenu est évalué via la checklist d’acceptation.
3. Si toutes les règles sont respectées, le contenu est publié.
4. Sinon, le contenu est rejeté ou réécrit.

6. Cas d’erreur¶

Un contenu est rejeté si au moins un des cas suivants est détecté :

• Présence d’un terme interdit.
• Présence d’une séquence logique décrivant un fonctionnement.
• Présence d’un schéma explicatif exploitable.
• Ambiguïté laissant supposer un procédé spécifique.

7. Critères d’acceptation (testables)¶

Un contenu est conforme si et seulement si :

• Il ne contient aucun terme de la liste interdite.
• Il ne contient aucun enchaînement d’actions techniques.
• Chaque affirmation peut être classée dans une catégorie autorisée (cf. invariant 3).
• Les pages légales utilisent des informations identiques pour les mêmes notions (hébergement, données).

8. Scénarios de test (Given / When / Then)¶

Given un contenu public candidat When une revue est effectuée Then la checklist ne détecte aucun terme interdit ni description procédurale.

9. Hypothèses explicites¶

• Aucun dépôt INPI n’a été effectué à la date de publication du contenu.
• Une spécification post‑INPI distincte prendra le relais immédiatement après dépôt.

10. Points à clarifier¶

• Date et condition exacte de bascule vers la spécification post‑INPI.
• Responsable désigné du contrôle éditorial.
• Processus d’archivage des versions publiées.