Protéger les livrables de code d'agence avec une preuve blockchain

2026-10-08 timestamp git blockchain proof

Protéger les livrables de code d’une agence avec une preuve blockchain

Elena dirige une équipe de développement de cinq personnes. Il y a onze mois, elle a signé avec un client pour un portail client : trois jalons, prix fixe, facturation à la livraison. Les jalons un et deux se sont bien passés. Le jalon trois a été livré un vendredi de septembre — fonctionnalités complètes, testé, déployé dans l’environnement de préproduction du client. Puis la facture est arrivée, et le client est devenu silencieux.

Deux semaines plus tard, la réponse : « Le module de reporting n’a jamais réellement été livré. Nous ne paierons pas la facture finale, et nous demandons un avoir pour le retard. »

Elena a des preuves. Enfin, plus ou moins. Il y a un fil d’e-mails où le propre chef de produit du client a écrit « ça a l’air bon, on testera la semaine prochaine ». Il y a un dossier Google Drive partagé avec les spécifications exportées. Et il y a le dépôt GitHub — plus de 400 commits se terminant exactement quand elle dit qu’ils se sont terminés, avec le module de reporting livré six semaines avant la facture.

Rien de tout cela n’est neutre. Le fil d’e-mails est une guerre de captures d’écran. Le dossier Drive contient des fichiers dont les dates de modification peuvent être contestées par le client (et l’ont été). L’historique Git vit dans une organisation que le client copossède, et les dates de commit peuvent être réécrites avec un simple git rebase et un force push. Dans un litige de paiement, « nous avons des logs internes » ne vaut à peu près rien — c’est une preuve que vous avez produite sur vous-même, sur des systèmes que vous contrôlez.

Cet article est un guide pratique pour les agences qui veulent l’inverse : un enregistrement qu’aucune des deux parties ne contrôle, qui ne nécessite pas la bonne volonté du client pour être vérifié, et qui survit au changement de dépôt, d’hébergeur ou de version du client.

La preuve cryptographique d’existence résout exactement ce problème. Et depuis 2026, vous n’avez plus besoin de comprendre la cryptographie pour l’utiliser — la couche managée fait le travail.

Pourquoi la preuve blockchain compte pour les agences (pas seulement pour les patent trolls)

L’horodatage blockchain est classé dans la catégorie « défense de brevets », c’est pourquoi la plupart des agences l’ignorent jusqu’au jour où elles en ont besoin. Mais les patent trolls ne sont pas le risque quotidien d’un studio de dev. Les clients avec un problème de trésorerie le sont.

Quatre situations concrètes où un enregistrement de commits ancré dans Bitcoin s’amortit tout seul :

Litiges de paiement. Vous pouvez prouver la date exacte à laquelle un jalon a été commité — pas quand une facture a été envoyée, pas quand quelqu’un a dit « c’est fait » sur Slack. La date est dérivée d’un bloc Bitcoin, pas de l’horloge de votre serveur ni de celle du client.
Protection contre la responsabilité. Les arguments de dérive du périmètre reposent généralement sur quand quelque chose a été convenu par rapport à quand cela a été construit. Un enregistrement immuable, jour par jour, de ce qui existait à chaque étape du projet vous permet de montrer qu’une demande de modification est arrivée après la livraison, sans débattre du calendrier de qui que ce soit.
Protection du portfolio et de la réutilisation. La plupart des agences possèdent une bibliothèque de composants — un module d’authentification, un adaptateur de facturation, une intégration CMS — qui apparaît dans une douzaine de projets clients. Prouver que vous l’avez créée, et quand, vous protège si un ancien client prétend que vous avez copié son code.
La confiance client comme argument de vente. Un pack de livraison qui inclut un certificat d’auteur vérifiable se lit différemment dans une négociation d’achat qu’un PDF que vous avez généré vous-même.

Ce n’est pas principalement une histoire de brevets. Si vous cherchez l’angle antériorité — invalider des brevets larges, protéger des secrets commerciaux avant dépôt — c’est couvert dans l’article frère sur la protection de l’antériorité pour les startups logicielles. Ici, nous restons sur la relation commerciale.

Un guide pratique : mettre en place la preuve blockchain pour les dépôts d’une agence

L’installation complète se fait en cinq étapes, et quatre d’entre elles sont à faire une seule fois. Rien ici n’oblige vos développeurs à apprendre un nouvel outil ni à changer une seule commande.

Étape 1 — Installer l’application GitHub Timestamp GIT

Installez l’application sur les dépôts que vous utilisez pour le travail client. En mode Standard, l’application GitHub lit automatiquement le hash du commit HEAD de chaque dépôt surveillé et écrit les preuves dans une branche dédiée (dans le même dépôt ou dans un dépôt fantôme séparé, à votre choix). Elle nécessite un accès en lecture seule au dépôt source et un accès en lecture-écriture au dépôt cible où les preuves sont déposées.

Faites-le une fois, au début de la mission, pas après le début du litige. Un horodatage créé pendant un désaccord ne vaut qu’une fraction de celui créé pendant une livraison normale.

Étape 2 — Laisser l’ancrage nocturne se faire

Il n’y a pas d’étape par commit. Les hash de commit sont détectés via des webhooks et mis en file d’attente en mémoire. Chaque nuit, un worker regroupe tout ce qui est en attente, construit des fichiers manifeste par dépôt, construit un arbre de Merkle et ancre la racine de Merkle dans la blockchain Bitcoin via le protocole OpenTimestamps en utilisant des calendriers publics.

La confirmation Bitcoin prend normalement environ trois heures, donc les preuves sont réécrites quelques heures après l’exécution du lot. De votre côté : vous poussez du code, et le lendemain matin le travail de la veille est ancré.

Étape 3 — Mettre le badge de vérification sous les yeux du client (avec tact)

Des badges intégrables sont disponibles pour votre README et pour les rapports de livraison. N’importe qui avec le lien peut vérifier l’horodatage via la page de statut publique — pas de compte, pas de connexion.

# Get ready-made badge markdown for your delivery report or README
curl -s https://timestampgit.dev/api/badgeLink/your-agency/client-portal

Le badge est un snippet compatible Shields.io, donc il s’insère dans un README, une page Notion ou le PDF que vous envoyez avec une facture. Sur les dépôts privés, l’URL de statut porte un HMAC chiffré afin que seules les personnes autorisées puissent lire le statut — la preuve elle-même reste publique et vérifiable, les métadonnées ne fuient pas.

Étape 4 — Exporter les certificats et les registres d’audit aux jalons

À chaque jalon, récupérez la paperasse et joignez-la à la facture.

# Full audit ledger as CSV — every anchored commit, every date
curl -s -o audit-client-portal.csv \
  "https://timestampgit.dev/api/audit/your-agency/client-portal"

# Per-day PDF certificate — include with the handover pack
curl -s -o certificate-2026-09-30.pdf \
  "https://timestampgit.dev/api/report/your-agency/client-portal/2026-09-30"

La page de statut du dépôt vous donne les mêmes données visuellement : longévité des preuves, date d’ancrage la plus ancienne, régularité quotidienne, le bloc Bitcoin et la transaction derrière chaque ancrage, une heatmap calendaire, et le CSV et le PDF téléchargeables. L’endpoint /api/statusSummary/{user}/{repo} renvoie un résumé combiné si vous voulez l’intégrer dans un tableau de bord interne.

Étape 5 — (Optionnel) Mode Enterprise ZK pour les clients sensibles

Certains contrats clients — défense, fintech, tout ce qui comporte une clause de PI stricte — interdisent l’accès tiers au code source. Le mode Enterprise ZK répond à cela : une GitHub Action de 12 lignes s’exécute dans votre infrastructure et ne pousse que les hash de commit vers l’API Timestamp GIT. Votre code source ne quitte jamais votre environnement, et seul le dépôt cible a besoin d’un accès en écriture.

Optionnel : Docker auto-hébergé

Si un client exige un fonctionnement en air-gap ou une résidence des données sur votre propre matériel, Timestamp GIT est livré sous forme d’image Docker. Le fichier Compose de démarrage rapide :

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

L’application est sur http://localhost:8080. Un assistant de configuration au premier lancement vous guide à travers la connexion de l’application GitHub et la configuration de l’instance. Une licence de démonstration à durée limitée pour l’évaluation peut être demandée sur la page de licence Docker.

Ce qu’il faut éviter en utilisant la preuve blockchain pour le travail client

Cinq erreurs que les agences commettent ici, par ordre de fréquence à peu près décroissant :

Se fier aux logs Git internes seuls. Ils sont modifiables, ils sont stockés sur une infrastructure que vous ou le client contrôlez, et lors d’un audit ils sont écartés comme intéressés. Une date de commit provenant de GitHub est une affirmation ; un hash de commit à l’intérieur d’un bloc Bitcoin est une preuve.
Essayer de faire le protocole à la main. Vous pouvez piloter vous-même la machinerie OpenTimestamps sous-jacente avec des outils en ligne de commande et vos propres soumissions de calendrier — c’est la manière difficile, cela nécessite un workflow par commit que vos développeurs oublieront, et cela produit exactement le résultat souhaité avec environ cent fois plus de maintenance. La couche managée existe pour que personne dans votre équipe n’ait jamais à y penser.
Horodater uniquement à la fin du projet. Une preuve unique en fin de projet dit « ceci existait à la date X ». Une chaîne nocturne dit « ce commit existait à cette date, et ce commit à cette date, jusqu’au bout ». Quand un client conteste une chronologie plutôt qu’un livrable, la granularité fait toute l’affaire.
Garder la preuve pour soi. Une preuve que l’autre partie ne peut pas vérifier est une preuve qu’elle contestera. Mettez le badge dans le README, envoyez le lien de statut, joignez le certificat PDF.
Ignorer les exigences de confidentialité du client. Si le contrat interdit l’accès tiers au code, utilisez le mode Enterprise ZK ou l’auto-hébergement. Ne supposez pas discrètement que « hash uniquement » satisfait une clause qui dit « aucun tiers ».

Comment Timestamp GIT s’intègre dans le workflow de votre agence

L’objectif de conception est que l’horodatage soit invisible jusqu’à ce que vous en ayez besoin :

Zéro configuration pour les développeurs. Installez l’application GitHub une fois. Chaque commit vers un dépôt surveillé est mis en file d’attente automatiquement ; le lot s’exécute chaque nuit. Pas de nouvelles commandes, rien à installer sur les machines des développeurs.
Architecture zero-knowledge. Timestamp GIT ne voit, ne copie ni ne stocke jamais votre code source. Il horodate des hash de commit. L’empreinte de l’étape un est un hash à sens unique de l’état du dépôt — rien de votre implémentation n’en est récupérable.
Vérification indépendante du fournisseur. La preuve est un reçu .ots ancré dans Bitcoin. La vérification dépend de SHA-256 et des données de bloc Bitcoin — aucun format propriétaire. N’importe qui peut télécharger le reçu et le vérifier avec les outils OpenTimestamps standards contre la blockchain, même si Timestamp GIT disparaissait demain. Il y a un guide pas à pas dans comment vérifier l’horodatage Bitcoin d’un dépôt Git.
Des points d’intégration adaptés à la paperasse d’agence. Une API REST pour le statut, le CSV d’audit et les certificats PDF ; des badges intégrables pour les README et les documents de livraison ; une page de statut publique que les clients peuvent mettre en favori.
Une tarification adaptée à l’échelle d’une agence. Open Source (gratuit) pour les dépôts publics, Pro Agency à 49 $/mois pour les dépôts privés, Enterprise ZK à 199 $/mois quand un contrat exige l’isolation. Détails sur la page de tarification.

Pour les équipes qui veulent la mécanique plutôt que le guide, l’article technique complémentaire est horodatage Git automatisé : comment une application GitHub ancre chaque commit.

FAQ

Dois-je changer la façon dont mes développeurs commitent le code ?

Non. Une fois l’application GitHub Timestamp GIT installée sur un dépôt, chaque commit est détecté automatiquement et son hash est mis en file d’attente pour l’ancrage Bitcoin nocturne. Les développeurs continuent d’utiliser leur workflow Git normal sans commandes ni outils supplémentaires.

Les clients peuvent-ils vérifier la preuve eux-mêmes ?

Oui. Vous pouvez intégrer un badge de vérification dans votre README ou votre rapport de livraison qui renvoie vers une page de statut publique. Les clients peuvent aussi télécharger le fichier de reçu .ots et le vérifier indépendamment contre la blockchain Bitcoin en utilisant les outils OpenTimestamps standards.

Et si un client exige qu’aucun tiers ne voie jamais le code ?

Utilisez le mode Enterprise ZK, où une GitHub Action de 12 lignes s’exécute sur votre infrastructure et ne pousse que les hash de commit vers l’API Timestamp GIT. Votre code source ne quitte jamais votre environnement. Vous pouvez aussi auto-héberger Timestamp GIT en utilisant l’image Docker fournie pour un contrôle total.

Combien de temps faut-il pour qu’un commit soit ancré dans Bitcoin ?

Les hash de commit sont regroupés quotidiennement et ancrés dans un bloc Bitcoin via le protocole OpenTimestamps. La confirmation Bitcoin prend généralement environ trois heures, après quoi la preuve est immuable et vérifiable.

Cela remplace-t-il un contrat ?

Non. Cela remplace la partie la plus faible d’un litige contractuel : le relevé factuel de ce qui existait quand. Votre contrat détermine qui doit quoi ; l’horodatage détermine ce qui était vrai à une date donnée.

Conclusion

Le litige d’Elena s’est résolu comme ceux-ci se résolvent habituellement — un paiement partiel et un client perdu. La partie frustrante n’était pas l’argent. C’était qu’elle avait raison et n’avait aucun moyen de le démontrer d’une manière qu’un tiers accepterait.

C’est le fossé que la preuve blockchain comble pour les agences. Pas la guerre des brevets, pas le futur abstrait — le mardi ordinaire où un client décide que la facture est facultative, et où votre seule défense est un enregistrement qu’aucun de vous deux ne peut modifier.

Installez l’application GitHub Timestamp GIT sur vos dépôts clients, laissez l’ancrage nocturne tourner, et joignez le certificat à votre prochaine facture. Cela prend environ dix minutes une seule fois, et cela change le ton de chaque conversation de livraison par la suite.

Articles liés

Protéger les livrables de code d'agence avec une preuve blockchain