Ackify CE : preuve de lecture cryptographique en Go + Vue3

Posté par  . Édité par Xavier Teyssier, Benoît Sibaud et Julien Jorge. Modéré par Julien Jorge. Licence CC By‑SA.
Étiquettes :
24
27
nov.
2025
Golang

Ackify CE est une plateforme open-source (AGPL v3) permettant de générer des preuves de lecture cryptographiquement vérifiables pour des documents internes.

Le problème

Les organisations doivent souvent prouver qu'un collaborateur a lu un document (politique RGPD, charte de sécurité, formation obligatoire). Les solutions existantes sont soit trop lourdes (signature électronique qualifiée comme DocuSign à 10-30€/utilisateur/mois), soit non sécurisées (simple email).

La solution

Ackify génère des preuves de lecture cryptographiques avec :

  • Signatures Ed25519 (même algo que SSH)
  • Horodatage immutable (PostgreSQL triggers)
  • Hash chain blockchain-like
  • Vérification offline possible

Cas d'usage

  • Validation de politiques internes (sécurité, RGPD)
  • Attestations de formation obligatoire
  • Prise de connaissance de procédures
  • Accusés de réception contractuels

Différence avec DocuSign

Ackify n'est pas une alternative à DocuSign pour des contrats juridiques. C'est une solution simple pour des besoins internes où la signature qualifiée est overkill.

N'hésitez pas si vous avez des questions techniques !

Installation

curl -fsSL https://raw.githubusercontent.com/btouchard/ackify-ce/main/install/install.sh | bash
cd ackify-ce
nano .env  # Configurer OAuth2
docker compose up -d

Installation complète en ~5 minutes.

Stack technique

Backend

  • Go 1.24 (Clean Architecture / DDD)
  • PostgreSQL 16
  • Chi Router
  • OAuth2 (Google, GitHub, GitLab, custom) ou Magic Link (passwordless)

Frontend

  • Vue 3 + TypeScript
  • Tailwind CSS
  • i18n (FR, EN, ES, DE, IT)

DevOps

  • Docker distroless < 30 MB
  • CI/CD GitHub Actions
  • Tests : 72,6% couverture (180 tests unitaires + 33 intégration)

Aller plus loin

  • # iso27001

    Posté par  . Évalué à 4 (+2/-0).

    bonjour,

    très intéressant, on est en plein audit iso27001 et on a pas mal de chose à faire "signer" aux employés. Aujourd'hui ils éditent le wiki dans gitlab pour dire qu'ils ont lu et quand. La trace reste dans le log du git du wiki. Ca à l'air suffisant pour l'auditeur blanc pour le moment. A voir pour le grand jour J.

  • # Preuve?

    Posté par  (site web personnel) . Évalué à 4 (+2/-0).

    Ayant déjà été confronté à ce problème, le mot "preuve" ici me parait mal adapté.

    En effet, l'administrateur de la base de données peut tout à fait changer l'état "lu"/"non lu" et régénérer la chaîne de hash. Moins facile que juste changer un flag, oui, mais pas d'une grande difficulté.

    C'est pourquoi les preuves sont toujours externes, sous la responsabilité d'un tiers.

    • [^] # Re: Preuve?

      Posté par  . Évalué à 4 (+4/-0).

      Vous avez raison sur le plan théorique - un admin avec accès BDD et à la clé privée Ed25519 pourrait forger une signature. C'est d'ailleurs vrai de tout système, y compris les tiers de confiance qui ont leurs propres admins.
      Le terme "preuve" ici désigne une preuve vérifiable cryptographiquement dans le contexte d'un litige collaborateur/employeur, pas une preuve contre l'organisation elle-même. Pour ce cas d'usage (le plus fréquent), la signature Ed25519 avec horodatage est juridiquement solide.
      Pour les cas nécessitant une preuve opposable à l'organisation, l'ancrage blockchain ou l'horodatage RFC 3161 sont effectivement des options

  • # Preuve de lecture alternative

    Posté par  (site web personnel) . Évalué à 3 (+2/-2).

    Demander au destinataire de trouver la phrase à double sens qui parle de fesses.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Bon de commande

    Posté par  . Évalué à 2 (+1/-0).

    Si j'ai bien suivi la solution ne serait pas adaptée pour la signature de bons de commandes (dans le secteur public) ?

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.