Comment les agences de développement peuvent prouver la livraison du travail avec Timestamp GIT

Maya dirige la livraison dans une agence de développement de 14 personnes. Mardi dernier, un client a refusé de payer un jalon de 38 000 $. La fonctionnalité était livrée, les tests passaient et la pull request avait été fusionnée le 14 juin. L’équipe achats du client affirme que le jalon est arrivé avec dix jours de retard, et que la facture devrait donc être réduite.

Maya exporte l’historique Git du dépôt. Il montre la fusion exactement au moment qu’elle indique. Mais l’avocat du client balaie l’argument : « C’est votre serveur, votre journal, vos dates. »

C’est à ce moment-là que Timestamp GIT change la donne.

Timestamp GIT est une GitHub App gérée pour les agences et les ateliers de développement qui ancre automatiquement chaque hash de commit dans la blockchain Bitcoin. Elle crée un enregistrement tiers immuable du moment exact où le travail existait — sans lire votre code source, sans installer d’outils CLI sur les machines des développeurs et sans demander à quiconque de devenir un expert en blockchain.

Le cauchemar de l’agence : quand un client conteste la livraison

Pour une agence, le litige de livraison suit généralement un schéma récurrent. Le client approuve un jalon au lancement. L’équipe construit la fonctionnalité, ouvre une pull request, obtient la validation du product owner côté client et fusionne. L’agence envoie la facture.

Des semaines plus tard, l’équipe financière du client affirme que le travail est arrivé en retard. Ou bien elle prétend que la fonctionnalité était incomplète à la date du jalon et a dû être reconstruite en interne. Parfois, l’affirmation est précise : « Le module tableau de bord n’existait pas le 15. »

Le premier réflexe de l’agence est de montrer le journal Git. Le hash de commit est là. L’horodatage est là. L’historique des branches est là.

Le problème : l’historique Git standard n’est pas une preuve indépendante. Il vit sur une infrastructure que vous contrôlez. Les dates peuvent être réécrites, rebasées, poussées en force ou hébergées sur un serveur que vous administrez. Dans un litige juridique ou d’achat, l’autre partie peut le rejeter comme étant intéressé — parce que techniquement, c’est le cas.

Ce dont Maya a besoin, ce n’est pas d’un autre journal. Elle a besoin de la preuve qu’une empreinte spécifique du code existait dans un bloc Bitcoin spécifique à un moment spécifique. Cette preuve ne peut pas être modifiée, antidatée ou supprimée par l’agence, le client, ni même par la plateforme qui l’a créée.

Timestamp GIT produit cette preuve automatiquement.

Pourquoi les agences de développement ont besoin d’une preuve cryptographique de livraison

Les agences font face à trois risques liés que l’historique Git interne ne résout pas.

Litiges de paiement

Un client peut retarder ou réduire un paiement en affirmant qu’un jalon est arrivé en retard, incomplet ou pas du tout. Les agences acceptent souvent un compromis parce que prouver la livraison coûte cher. Un reçu cryptographique change ce calcul : le client ne peut pas contester le moment où le commit existait lorsque la preuve est ancrée dans Bitcoin.

Responsabilité pour les délais manqués

Parfois, l’agence est accusée d’avoir causé le retard d’un lancement de produit. Si le litige s’aggrave, l’agence doit montrer exactement quelles fonctionnalités ont été terminées à quelles dates. Les horodatages au niveau des commits créent une chronologie précise qui ne dépend pas de la parole de l’agence.

Allégations de non-exécution

Un client peut affirmer que l’agence n’a jamais livré une base de code particulière, ou qu’il a dû repartir de zéro. Les hashes de commit horodatés relient le travail livré à un point vérifiable dans le temps, ce qui rend ces allégations beaucoup plus difficiles à soutenir.

Les preuves traditionnelles — e-mails, journaux internes de gestion de projet, captures d’écran, journaux d’accès serveur — sont souvent traitées comme faibles ou circonstancielles. Les horodatages ancrés dans Bitcoin sont différents : ils sont mathématiquement vérifiables et immuables.

Timestamp GIT utilise une architecture zero-knowledge. Le code source de l’agence ne quitte jamais le dépôt. Timestamp GIT extrait uniquement le hash de commit — une empreinte cryptographique unique de l’état du dépôt — et ancre ce hash dans Bitcoin via le protocole OpenTimestamps. Le résultat est un reçu .ots qui peut être vérifié contre la blockchain Bitcoin.

Pour comprendre pourquoi ce type de preuve compte au-delà des litiges de livraison, voir Preuve d’existence pour le code : ce que c’est et pourquoi c’est important.

Les garanties opérationnelles comptent pour les agences :

• Ancré dans Bitcoin : la preuve est publique, immuable et vérifiable pour toujours.
• Indépendant du fournisseur : la vérification repose uniquement sur SHA-256 et les données des blocs Bitcoin. Aucun verrouillage propriétaire.
• Sécurité zero-knowledge : Timestamp GIT ne voit, ne copie et ne stocke jamais le code source.
• Preuve prête pour les tribunaux : la preuve est une chaîne cryptographique du hash de commit au bloc Bitcoin.

Un guide pratique : configurer Timestamp GIT pour votre agence

Le chemin le plus court est la GitHub App en mode Standard. La configuration est conçue pour ne nécessiter aucune maintenance.

Étape 1 : Installer la GitHub App Timestamp GIT

Installez la GitHub App sur votre organisation et accordez-lui l’accès aux dépôts clients que vous souhaitez surveiller. En mode Standard, l’app lit uniquement le hash du commit HEAD de chaque dépôt surveillé. Elle ne lit pas le contenu des fichiers, les diffs des pull requests ni le code source.

L’app 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 seront stockées. Vous pouvez conserver les preuves dans une branche dédiée du même dépôt ou dans un dépôt miroir séparé.

Étape 2 : Configurer la surveillance des projets clients

Une fois l’app installée, chaque nouveau commit est détecté automatiquement via les webhooks. Il n’y a aucune étape manuelle par commit, aucun script à exécuter et aucune configuration de poste de travail développeur.

Étape 3 : Laisser le worker nocturne ancrer le travail de la journée

Timestamp GIT regroupe les hashes de commit en attente chaque nuit. Il crée des fichiers manifest, construit un arbre de Merkle, génère des preuves OpenTimestamps et ancre la racine de Merkle dans un bloc Bitcoin.

La confirmation Bitcoin prend généralement environ trois heures, donc la livraison de la preuve n’est pas instantanée. Elle se produit automatiquement après la confirmation du bloc.

Étape 4 : Recevoir les fichiers de reçu .ots

Timestamp GIT pousse le manifest et les fichiers de reçu .ots vers votre dépôt dans une branche d’horodatages dédiée ou un dépôt miroir. Ces fichiers deviennent votre archive de preuves à long terme.

Étape 5 : Montrer aux clients une preuve de livraison en temps réel

Vous n’avez pas besoin de donner aux clients l’accès à votre dépôt privé. Timestamp GIT fournit des pages de vérification publiques, des badges intégrables, des rapports PDF et un registre d’audit CSV.

Par exemple, vous pouvez interroger les informations du dernier bloc Bitcoin ancré pour un dépôt :

curl -s https://timestampgit.dev/api/statusLast/acme-agency/client-portal

Le tableau de bord public montre la date d’ancrage la plus ancienne, la régularité quotidienne, les données de bloc et de transaction Bitcoin, ainsi qu’une heatmap calendaire. Les clients peuvent utiliser un lien de badge pour consulter le statut de vérification et télécharger le reçu .ots pour une vérification indépendante.

Pour le flux d’automatisation plus large de la GitHub App, voir Automatiser l’horodatage des commits Git avec une GitHub App.

Alternatives auto-hébergées et entreprise

Si vous avez besoin d’un déploiement air-gapped ou auto-hébergé, Timestamp GIT est disponible sous forme d’image Docker. Un fichier Compose typique ressemble à ceci :

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

Démarrez-le avec :

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

L’app est disponible sur http://localhost:8080. Un assistant de configuration vous guide pour connecter votre GitHub App et configurer l’instance. Une licence de démonstration à durée limitée est disponible depuis la page Docker License.

Pour une isolation maximale, le mode Enterprise ZK exécute une GitHub Action de 12 lignes sur votre infrastructure. Elle pousse uniquement le hash de commit vers l’API Timestamp GIT, de sorte que le code source ne quitte jamais votre environnement. Dans ce mode, Timestamp GIT nécessite un accès en lecture-écriture uniquement au dépôt cible — aucun accès en lecture au dépôt source.

Si vous évaluez l’approche gérée par rapport à l’horodatage manuel, voir Alternative à OpenTimestamps : horodatage géré pour Git.

Ce qu’il faut éviter pour prouver la livraison du travail

Ne vous fiez pas uniquement à l’historique Git interne ou aux journaux serveur

Les journaux internes peuvent être réécrits, antidatés ou contestés comme étant intéressés. Ce sont des preuves de soutien utiles, mais pas des preuves indépendantes. Ancrez le hash de commit quelque part d’immuable.

Évitez les processus d’horodatage manuels

Les processus manuels sont sujets aux erreurs et incohérents. Les équipes oublient de les exécuter, utilisent la mauvaise branche ou perdent les reçus. Utilisez une automatisation qui capture chaque commit.

N’exposez pas le code source à des services d’horodatage tiers

Un système de preuve de livraison ne devrait pas exiger le téléversement du code de votre client vers un serveur externe. Timestamp GIT traite uniquement les hashes de commit, pas le code source. La conception zero-knowledge protège à la fois votre agence et votre client.

N’attendez pas qu’un litige survienne

Au moment où un client affirme qu’un jalon n’est jamais arrivé, il est trop tard pour constituer la preuve. Commencez l’horodatage dès le premier commit afin que chaque jalon dispose d’une chaîne de preuve ininterrompue.

FAQ

Comment Timestamp GIT prouve-t-il exactement quand un commit a été effectué ?

Timestamp GIT extrait le hash de commit — une empreinte unique de votre code — et l’ancre dans la blockchain Bitcoin via le protocole OpenTimestamps. L’horodatage du bloc Bitcoin fournit un enregistrement immuable et publiquement vérifiable de l’existence du commit à ce moment-là.

Un client peut-il vérifier l’horodatage sans accès à mon dépôt privé ?

Oui. Timestamp GIT fournit une page de vérification publique et des badges intégrables. Le client peut utiliser le lien du badge pour consulter le statut de vérification et télécharger le reçu .ots, qui peut être vérifié indépendamment contre la blockchain Bitcoin sans exposer votre code source.

Que se passe-t-il si le client conteste l’authenticité de l’horodatage ?

L’horodatage est ancré dans Bitcoin, qui est mathématiquement immuable. N’importe qui peut vérifier la preuve en utilisant la blockchain Bitcoin et la chaîne cryptographique allant de votre hash de commit au bloc Bitcoin. Cette chaîne ne peut pas être falsifiée ni altérée, ce qui rend la preuve prête pour les tribunaux.

Timestamp GIT convient-il aux agences qui travaillent avec plusieurs clients et dépôts ?

Absolument. La GitHub App peut surveiller plusieurs dépôts au sein de votre organisation. Le plan Pro Agency prend en charge les dépôts privés, et le tableau de bord fournit une vue d’ensemble de tous les commits horodatés, ce qui facilite la gestion des preuves pour de nombreux clients.

Conclusion : faites des litiges de livraison une chose du passé

Pour les agences et les ateliers de développement, la question « quand avez-vous livré ? » ne devrait jamais dépendre du journal serveur que le client choisit de croire. Timestamp GIT remplace cet argument par un reçu ancré dans Bitcoin.

Installez la GitHub App une fois, connectez vos dépôts clients, et chaque commit est automatiquement regroupé, enraciné dans un arbre de Merkle et ancré dans Bitcoin chaque nuit. Les preuves arrivent dans une branche dédiée ou un dépôt miroir. Les pages de vérification, les badges, les rapports PDF et les CSV d’audit offrent à vos clients un moyen digne de confirmer la livraison sans exposer le code source.

Les tarifs commencent avec le niveau Open Source pour les dépôts publics, le plan Pro Agency à 49 $/mois pour les dépôts privés, et Enterprise ZK à 199 $/mois pour les workflows basés sur GitHub Actions. Si vous avez besoin d’un déploiement auto-hébergé, la licence Docker est disponible avec une option de démonstration.

Commencez avec le niveau gratuit pour dépôts publics ou installez la GitHub App pour les dépôts de votre agence sur timestampgit.dev.

Articles connexes

• Preuve d’existence pour le code : ce que c’est et pourquoi c’est important
• Automatiser l’horodatage des commits Git avec une GitHub App
• Alternative à OpenTimestamps : horodatage géré pour Git