Un client attend une nouvelle version de S3Guardian. Son besoin paraît simple : répliquer ses données, installer les mises à jour sans perdre le contrôle et pouvoir vérifier ce qui lui a été livré. Pour l’équipe qui développe et maintient le programme, cette demande traverse pourtant plusieurs mondes : le code, les tests, les décisions de livraison, l’installation et le support.
Entre ces étapes, les informations se dispersent facilement. Un commit décrit une correction, un rapport confirme un test, un ticket explique une décision. Quelques semaines plus tard, retrouver pourquoi une version a été livrée, ce qu’elle contenait et ce qui a réellement été installé devient une enquête.
Le scénario associant KARL Git, KARLCore, KARL Signing, KARL Evidence et KARL Support consiste à conserver cette continuité, puis à en extraire des preuves que le client pourra vérifier indépendamment.
Une correction commence par un fait à reproduire
Prenons un incident concret : pendant une réplication, une interruption laisse un fichier incomplet à destination. Le client ouvre un dossier dans KARL Support. Il indique la version de S3Guardian utilisée, décrit les circonstances et transmet les éléments utiles à l’investigation.
Le dossier s’enrichit progressivement. Le support consigne les observations, distingue les faits des hypothèses et rattache les essais au problème signalé. Une première piste est abandonnée. Une seconde permet de reproduire le comportement.
Cette distinction compte. Une hypothèse inscrite dans un ticket ne doit pas devenir, par le simple passage du temps, une cause démontrée.
KARLCore joue ici le rôle de couche de mémoire durable et gouvernée. Il conserve les événements et les références qui permettent de retrouver le contexte : quel état du programme était concerné, quels éléments ont été enregistrés, par qui et dans quel ordre. Cette mémoire porte sur les informations effectivement capturées ; elle ne reconstitue pas les opérations restées en dehors du parcours.
Du diagnostic au changement de code
L’équipe de développement reprend le dossier dans KARL Git. Elle rattache la correction au problème identifié et prépare un test capable de reproduire l’incident.
Avant la modification, le test échoue. Après la correction, il réussit. D’autres essais vérifient que le changement n’a pas dégradé la réplication ordinaire, la reprise après interruption ou le traitement des erreurs.
Les résultats utiles rejoignent le dossier de la version. Le commit apporte la modification ; les tests expliquent ce qui a été contrôlé. La décision de retenir cette correction est enregistrée avec ses éventuelles réserves.
Le lien entre KARL Git et la mémoire KARLCore permet de suivre cette progression sans réduire l’histoire à l’état final du dépôt. On peut retrouver le problème initial, la correction retenue et les éléments disponibles au moment de la décision.
Cela ne signifie pas que le programme est exempt de bugs. Cela permet de dire précisément quelle correction a été réalisée et sur quels contrôles repose la livraison.
Avant de livrer, figer ce que l’on remet au client
La version est prête. L’équipe rassemble le programme à distribuer, les références du code, les résultats de tests et les informations de version. Les empreintes des livrables permettent d’identifier les fichiers exacts concernés.
KARL Evidence assemble ces éléments dans un pack de preuves de release. Il calcule les empreintes des pièces et prépare un manifeste qui décrit le contenu du pack. Une fois ce manifeste figé, KARL Signing applique la politique de signature prévue pour cet usage.
Les responsabilités restent distinctes. KARL Evidence construit le dossier exportable. KARL Signing sélectionne la clé et le fournisseur autorisés, puis réalise la signature. KARLCore conserve la mémoire gouvernée du parcours dont les applications ont sélectionné les éléments.
A savoir :
- Le choix cryptographique comporte deux niveaux.
- Ed25519 et RSA-PSS-SHA256 eux sont des algorithmes de signature.
- PKCS#11 est une interface qui permet de communiquer avec un fournisseur cryptographique.
Une organisation peut ainsi utiliser un fournisseur logiciel ou choisir un fournisseur accessible par PKCS#11, selon sa politique et les mécanismes pris en charge. FreeHSM v2.3.1 (licence Apache 2.0), développé par Afchine Madjlessi, constitue une option logicielle sélectionné pour ce raccordement dans l'Evidence pack.
L’utilisation de PKCS#11 ne signifie pas, à elle seule, que les clés sont protégées par un équipement matériel. Dans tous les cas, la clé privée reste du côté du fournisseur de signature : elle n’est pas jointe au pack remis au client.
L’installation ouvre un second chapitre
Le client reçoit la version de S3Guardian et le pack associé à sa livraison. L’installation peut alors être suivie dans KARL Support.
L’intervenant enregistre la version installée, les opérations réalisées et les résultats des tests de recette. Les informations sélectionnées doivent être utiles à la preuve sans exposer inutilement les secrets ou les données du client.
Si un comportement inattendu apparaît, le dossier reste ouvert. Les observations et les nouvelles interventions prolongent la chronologie. La livraison initiale conserve son identité ; une correction ultérieure donne lieu à une nouvelle version et à ses propres preuves.
Lorsque la recette est terminée, la validation du client peut être enregistrée avec son contexte et son périmètre. Elle ne transforme pas les essais réalisés en garantie universelle : elle indique ce qui a été accepté dans cet environnement.
KARL Evidence peut alors produire un second pack, consacré à l’installation. Celui-ci référence la release livrée et rassemble les éléments retenus pour documenter son installation et sa validation.
Les deux packs répondent à deux questions différentes : qu’avons-nous livré, puis qu’avons-nous installé et contrôlé chez ce client ?
Vérifier sans rappeler le fournisseur
Le client conserve les packs et peut les transmettre à un auditeur. Avec KARL Evidence PACK et un vérificateur compatible avec leur format, il contrôle les empreintes des pièces et les signatures sur une machine déconnectée.
Il lui faut les éléments publics nécessaires à la vérification et des ancres de confiance approuvées séparément. Une clé présente dans un pack ne devient pas digne de confiance du seul fait qu’elle y figure.
Cette vérification ne nécessite ni connexion à KARLCore, ni accès à KARL Git ou à KARL Support, ni clé privée, ni instance de FreeHSM. Le rapport précise les contrôles réussis, les anomalies et les points qui restent indéterminés.
Les formats historiques et le nouveau format commun doivent toutefois être distingués : ce parcours suppose de choisir le vérificateur adapté à chaque pack.
Le client dispose ainsi d’une histoire documentée, depuis le problème reproduit jusqu’à la version installée. Il peut examiner les éléments conservés et contrôler leur intégrité sans dépendre d’une consultation permanente des services du fournisseur.
La signature ne prouve pas qu’un diagnostic était juste ou qu’un logiciel ne contient aucun défaut. Elle permet de vérifier que les éléments présentés sont bien ceux qui ont été scellés avec la clé identifiée. C’est sur cette base précise que le dialogue entre développeur, support et client devient plus solide.
