Un algorithme ou une fonctionnalité peut être revendiqué par n'importe qui
Premier scénario : un développeur freelance livre une feature à un client, qui prétend ensuite en être l'auteur intellectuel et refuse de payer. Deuxième scénario : un développeur indépendant crée un algorithme original, un concurrent sort le même quelques mois plus tard et conteste la paternité. Dans les deux cas, un commit Git ou un email ne suffit pas — ils peuvent être antidatés ou contestés. Seule une preuve horodatée par une autorité de tiers de confiance est techniquement inattaquable.
Une empreinte certifiée de votre code, en dehors de votre dépôt Git
Je finalise une version stable de mon code ou d'un livrable technique.
Je génère une preuve horodatée du fichier ZIP de mon projet avant livraison ou publication.
Je peux prouver que cette version précise existait à cette date, indépendamment de Git.
Le code ne quitte jamais mon appareil. Seule l'empreinte SHA-256 est transmise.
Formats acceptés : ZIP, TAR.GZ, JS, PY, SQL, binaires compilés — tous formats
3 étapes, 30 secondes
- Déposez votre fichier: ZIP du projet, fichier source, binaire compilé…
- Certification automatique: Hash SHA-256 calculé dans le navigateur + horodatage RFC 3161 via FreeTSA
- Téléchargez votre Proof Pack: Certificat PDF lisible + jeton .tsr vérifiable par n'importe quel outil compatible RFC 3161
Pourquoi pas simplement utiliser Git ?
Git est un outil de versionnement, pas un outil de preuve externe.
| Critère | Commit Git | GitHub timestamp | ProofStamper |
|---|---|---|---|
| Antidatable | Oui (git commit --date) | Non | Non (TSA externe) |
| Dépendant d'une plateforme | Non | Oui (GitHub) | Non |
| Confidentialité du code | Local | Hébergé | 100% local |
| Vérifiable indépendamment | Non | Non | Oui (RFC 3161) |
| Preuve technique externe | Non | Non | Oui ✓ |
Protégez chaque étape clé de votre développement
- Livraison client — Prouvez la date exacte de remise d'un livrable technique.
- Dépôt de brevet logiciel — Documentez l'antériorité de votre invention avant toute publication.
- Algorithme propriétaire — Figez une version de votre algorithme avant partage ou collaboration.
- Version avant open source — Horodatez votre code avant de le publier sous licence ouverte.
- Audit de conformité — Prouvez l'état exact d'un système à une date précise.
- Preuve de non-régression — Certifiez qu'une version passait les tests à une date donnée.
Questions fréquentes
- Un commit Git ne suffit-il pas comme preuve ?
- Un commit Git peut être antidaté avec la commande git commit --date. Il s'agit d'un outil de versionnement interne, pas d'une preuve indépendante. ProofStamper utilise une autorité d'horodatage tierce (RFC 3161) qui certifie la date de façon incontestable.
- Mon code source est-il envoyé sur vos serveurs ?
- Non, jamais. Tout le traitement se fait localement dans votre navigateur. Seule l'empreinte cryptographique (SHA-256) — un identifiant unique qui ne permet pas de reconstituer votre code — est envoyée pour obtenir l'horodatage.
- Puis-je horodater un projet entier en un seul fichier ZIP ?
- Oui. Compressez votre projet en ZIP ou TAR.GZ et déposez-le. L'empreinte SHA-256 couvre l'intégralité du contenu. Si un seul octet change, l'empreinte sera différente.
- Cette preuve est-elle utilisable dans un contexte de litige commercial ?
- Oui. Le certificat RFC 3161 est une preuve technique d'antériorité reconnue. Combiné avec un constat d'huissier, il constitue un élément probant solide pour établir la date d'existence d'un fichier.