Aller au contenu
toevan
Se connecterRéserver un pilote d’audit
Ouvrir le menuFermer le menu
Réserver un pilote d’audit

Le système de référence des contrôles au niveau du code

Chaque changement de code, scellé en preuve d’audit.

Calculé à partir du changement lui-même, pas déclaré par un pipeline.

Réserver un pilote d’auditVoir un exemple de rapport
  • Traitement UE · DPA
  • openssl · Rekor opt-in
  1. Vérifie ce que fait chaque changementÉvalue le code lui-même, pour qu’aucune étape du pipeline ne puisse déclarer un succès, et bloque la fusion avec la règle, le fichier et la ligne.
  2. Enregistre comment il est entréÀ partir de v1.4.0 : revues, approbations, fusions et déploiements en production, depuis l’enregistrement propre à GitHub, pas un script maintenu par votre équipe.
  3. Scelle chaque verdict en preuveSigné et chaîné, pour que votre auditeur le vérifie hors ligne sans nous faire confiance.

Fonctionne avec

  • GitHub
  • Kosli
  • Sigstore
  • Slack
  • Jira
  • Linear

Preuves pour

  • SOC 2
  • ISO/IEC 27001
  • PCI DSS v4.0
  • FedRAMP Moderate
  • HIPAA
  • GDPR
  • DORA
Piste de preuvespayments-apimain

  1. e58c44aAjout du webhook de remboursement

    BloquéSecret codé en dur dans refund.ts, ligne 42

    préc. 9f2c41asceau 4f2a9c1

  2. 3d10c97Lecture de la clé Stripe depuis l’environnement

    AcceptéLève le blocage sur e58c44a

    préc. 4f2a9c1sceau c81e07d

  3. 17aa93dJournalisation des événements de règlement

    ExceptionApprouvé par le responsable sécurité, expire le 14 nov.

    préc. c81e07dsceau 6b39f20

toevan audit verify --path evidence-clone --pub-key toevan.pub
  • Chaîne intacte sur 4 812 enregistrements
  • Chaque signature est valide avec la clé publiée
  • Vérifié hors ligne, sans compte Toevan

Les règles demandent au modèle de bien se comporter. Toevan vérifie qu’il l’a fait.

Les assistants IA écrivent désormais une grande part du code que les équipes réglementées fusionnent, plus vite qu’aucun processus de revue n’a été conçu pour l’absorber. Un fichier CLAUDE.md ou .cursorrules est une demande. Un gate de fusion est un contrôle, et l’enregistrement qu’il écrit est une preuve, calculée à partir du changement lui-même plutôt qu’attestée par le pipeline qui l’a exécuté.

Dans les entreprises du Fortune 50, le code généré par IA ajoutait plus de 10 000 nouveaux constats de sécurité par mois en juin 2025, soit dix fois le niveau de décembre 2024.Source : Apiiro, « 4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks » (2025)

Un gate, un enregistrement, toutes les vues dont un audit a besoin.

Toevan s’exécute à chaque pull request et sur main après chaque fusion, et à partir de v1.4.0 suit chaque changement du commit à la production : chaque fusion, chaque modification de vos règles de revue, chaque déploiement en production. Ce qu’il décide, il l’enregistre, et ce qu’il enregistre, votre équipe et vos auditeurs peuvent le voir.

Prévu pour v1.4.0

Enregistre comment chaque changement est entré.

À partir de v1.4.0, Toevan capture chaque fusion, approbation et modification de vos règles de revue depuis GitHub au fil de l’eau, et relie chaque déploiement en production au commit qu’il a livré. Rien ne passe entre deux instantanés.

  • Approbation indépendante sur le dernier commit, checks requis et règles en vigueur à la fusion
  • Règles de revue désactivées, contournements d’administrateur et push directs, capturés comme événements
  • Branches protégées et leurs règles, chaque modification étant scellée
  • Une page Process qui montre toutes les fusions et tous les changements de contrôles au même endroit
  • Chaque commit sur main rapproché de l’enregistrement qui l’y a amené, ou signalé avec sa raison

Prévuv1.4.1 : les branches de production que vous désignez, comme une branche de release, reçoivent la même population que main. Ensuite : correctifs sur les branches de release rapprochés par contenu.

Bloque le changement et dit exactement pourquoi.

Chaque pull request est contrôlée comme un check GitHub par rapport aux blueprints que vous adoptez. Une violation arrête la fusion en indiquant la règle, le fichier et la ligne exacts, et ce qu’il faut pour passer. Deep Check couvre ce qu’un contrôle avant fusion ne peut pas vérifier seul.

  • 28 types de contraintes déterministes en conformité, sécurité et architecture
  • Commente sur la ligne et publie son verdict sous forme de revue
  • Exceptions demandées depuis la pull request, avec un motif et une échéance
  • Correctifs suggérés, validés par le build et l’analyse du périmètre d’impact

Scelle chaque décision en preuve.

Chaque exécution du gate écrit un enregistrement signé, en ajout seul, rattaché au commit et à la version du jeu de règles en vigueur, et à partir de v1.4.0 il en va de même pour chaque fusion et chaque changement de règle. La chaîne se vérifie hors ligne, et les exports sont prêts pour votre auditeur.

  • Chaîné par hachage et signé, avec ancrage intégré sur adhésion dans le journal public Rekor de Sigstore (Enterprise aussi dans le sien)
  • Exports CSV et PDF par référentiel, dépôt et période
  • Conservation d’au moins trois ans, avec une copie dans votre propre dépôt

Montre l’état des contrôles comme un audit le demande.

Suivez chaque dépôt par rapport aux référentiels sur lesquels vous êtes audité, voyez les dérogations avant leur expiration, et donnez aux auditeurs externes un rôle en lecture seule pour les preuves et les rapports.

  • Un badge d’état pour le README de chaque dépôt, avec un lien vers l’enregistrement
  • Gestion des changements avec preuve du relecteur et de l’approbateur, à partir de v1.4.0
  • Vues pour les ingénieurs, l’audit interne et les auditeurs externes

Votre auditeur peut le vérifier sans nous faire confiance.

Chaque verdict scellé est une déclaration in-toto avec le prédicat SLSA verification summary, dans une enveloppe DSSE signée avec ECDSA P-256. Des outils courants vérifient un enregistrement sans compte Toevan ; rejouer toute la chaîne passe par le vérificateur Toevan, disponible sur demande auprès de Toevan. Dans l’application, Vérifier maintenant revérifie tout pour vous, et les verdicts signés peuvent aussi être poussés dans vos flux Kosli.

  1. Clonez les preuves, récupérez les clés

    Les preuves se trouvent sur une branche toevan/evidence de votre propre dépôt, à côté du code qu’elles décrivent : chaînées par hachage et en ajout seul. Chaque clé avec laquelle Toevan a signé, actuelle ou retirée, est publiée à une adresse publique, sans connexion.

  2. Vérifiez n’importe quel enregistrement avec openssl

    openssl vérifie un enregistrement sans logiciel Toevan : la signature, et que le fichier d’enregistrement est celui que nomme la déclaration. À partir de v1.4.0, les rapports et la branche de preuves affichent ces commandes.

    openssl dgst -sha256 -verify toevan.pub -signature sig.der pae.bin

  3. Ou vérifiez la signature avec cosign

    À partir de v1.4.0, Toevan documente une ligne cosign v2 qui vérifie la signature et le type de déclaration, pas le lien avec l’enregistrement.

    cosign verify-blob-attestation --key toevan.pub --type https://slsa.dev/verification_summary/v1 --signature <envelope> --check-claims=false --insecure-ignore-tlog <envelope>

  4. Rejouez toute la chaîne

    Une commande rejoue la chaîne hors ligne et vérifie chaque signature et chaque preuve Rekor ; si un enregistrement a été retiré ou modifié, la chaîne se rompt. Le vérificateur Toevan est disponible sur demande auprès de Toevan.

    toevan audit verify --path evidence-clone --pub-key toevan.pub

  5. Rapprochez le rapport

    Chaque rapport porte une empreinte de contenu : le SHA-256 du manifeste joint au PDF. À partir de v1.4.0, recomptez chaque commit arrivé sur main avec git et le CSV de population du rapport.

  6. Sur adhésion : confirmez l’ancrage public

    L’ancrage dans le journal de transparence public Rekor de Sigstore est intégré, sur adhésion de chaque organisation ; seuls les hachages d’enregistrements sont publiés. Les preuves d’inclusion montrent que chaque hachage a été consigné au moment de sa signature. Les organisations Enterprise peuvent aussi s’ancrer dans leur propre Rekor.

Vérification hors ligne
$ toevan audit verify --path evidence-clone --pub-key toevan.pubreplaying hash chain: 4,812 records✓ chain intact✓ 4,812 attestation signatures verify under the published key

Ce que contient un enregistrement

Un changement, tel que votre auditeur le voit en échantillonnant : comment il est entré et ce qu’il fait. Chaque fait indique comment il a été obtenu, pour que votre auditeur sache dans quelle mesure s’y fier. Les résultats de code sont scellés à chaque pull request dès aujourd’hui, les enregistrements de changement avec preuve de processus et les déploiements en production arrivent dans v1.4.0, et les copies vers les branches de release sont prévues. Les personnes apparaissent sous forme d’empreintes de leurs comptes GitHub.

rec_5b81d4e

northwind/payments-api · PR #1921

Un changement fusionné, signé et chaîné à l’enregistrement qui le précède.

Enregistrements : prévu pour v1.4.0Données d’exemple

Le changement

Prévu pour v1.4.0
Pull request
Rapporté + scellé
payments-api #1921 · Add tenant check to refund handler
Auteur · fusionné par
Rapporté + scellé
4be1…09c2 · 9d07…e3a4 · 13 oct. 2026, 10:41 UTC dans main
Commit de fusion
Rapporté + scellé
5b81d4e
Déployé en production
Rapporté + scellé
13 oct. 2026, 11:20 UTC · production (indicateur GitHub) · rec_9e41b07

Preuve de processus

Prévu pour v1.4.0
Approbations
Rapporté + scellé
9d07…e3a4, c58f…71d0 · toutes deux sur le dernier commit e81b2d0
Indépendant de l’auteur
Recalculé
Oui, par identifiant de compte GitHub
Checks requis
Rapporté + scellé
ci/test ✓ · ci/lint ✓ · toevan/gate ✓
Règles en vigueur
Rapporté + scellé
main-protection : 2 approbations, checks requis, commits signés
Signature du commit
Rapporté + scellé
Vérifiée par GitHub

Preuve issue du code

Actif aujourd’hui
Règles de conception
Recalculé
4 / 4 respectées
Codage sécurisé
Recalculé
7 / 8 respectées · secret-detection-high sous dérogation rec_b30e7c5
Couverture · moteur
Recalculé
98,1 % (gate 95 %) · toevan-engine 0.9.4

Chemin vers la production

Prévu
Copié vers la release
Recalculé
Rapproché de l’original revu par son contenu

Sceau

Signature
ECDSA P-256 · enveloppe DSSE · keyid 8c1f…e0a2
Enregistrement précédent
rec_b7e21f0
Ancrage public
Journal public Rekor de Sigstore · intégré, sur adhésion par organisation

Comment chaque fait a été obtenu

Chaque fait d’un enregistrement et d’un rapport porte l’une de six étiquettes, pour que votre auditeur sache dans quelle mesure s’y fier.

Recalculé
Toevan l’a calculé lui-même à partir du code ou de l’historique git.
Le refaire à partir des mêmes entrées et obtenir le même résultat.
Rapporté + scellé
GitHub l’a rapporté ; Toevan l’a capturé au moment de l’événement et signé.
S’y fier dans la mesure où vous vous fiez à GitHub. Toute modification ultérieure est détectable.
Déclaré + scellé
L’organisation l’a déclaré, par exemple un changement de ce qui est vérifié ; Toevan a signé la déclaration et son historique.
Voir qui a déclaré quoi, quand, et chaque modification ultérieure.
Enregistrement Toevan, non scellé
Conservé dans la base de données de Toevan mais non scellé dans le registre, comme une dérogation aujourd’hui. Aucune signature ne le protège.
Le considérer comme une déclaration de Toevan et demander à l’organisation l’approbation qui la fonde.
Consommé
Repris de l’enregistrement signé d’un autre système, comme une provenance de build, et relié par commit ou empreinte. Prévu.
Vérifier l’enregistrement d’origine de façon indépendante.
Non capturé
Aucune source fiable n’était disponible. Toevan ne le déduit pas.
L’obtenir auprès de l’organisation par d’autres moyens.

Complet seul. Connecté quand vous en avez besoin.

Toevan n’a besoin que de vos dépôts GitHub pour contrôler chaque changement, sceller les preuves et donner aux auditeurs ce qu’ils demandent, et à partir de v1.4.0 pour enregistrer chaque changement du commit à la production. Gardez Semgrep, Snyk ou CodeQL pour la profondeur, et si vous utilisez Kosli ou une plateforme GRC, les mêmes preuves y vont aussi.

Toevan

Système de référence des contrôles au niveau du code

Seul

  • Gate de pull request
  • Preuve scellée par changement
  • Exceptions avec échéance
  • Preuve de processus, v1.4.0
  • Badge d’état du README
  • Tableaux de bord d’audit
S’exécute sur vos dépôts GitHubConnecté

Où les preuves peuvent aller

  • Votre auditeur

    Vérifie n’importe quel enregistrement hors ligne, sans compte Toevan

    Sans compte

  • Kosli

    Attestations signées dans vos flows et trails

    Connecté

  • Sigstore Rekor

    Ancrage intégré des hachages d’enregistrements dans le journal public, sur adhésion ; Enterprise aussi dans sa propre instance

    Sur adhésion

  • Vanta, Drata ou votre registre

    Rapports joints par contrôle et par période

    Joindre les rapports

  • Slack, Jira, Linear et webhooks

    Pull requests bloquées et exceptions dans Slack et les webhooks ; tâches depuis Jira et Linear

    Connecté
  • Connecté aujourd’hui
  • Sur adhésion : intégré, par organisation
  • Fonctionne en parallèle : vous joignez les rapports de Toevan
  • Vérifié hors ligne avec des outils ouverts

Conçu pour l’audit, et honnête sur son périmètre.

Chaque contrôle que le logiciel peut prouver, cartographié par référentiel : ce que Toevan prouve aujourd’hui, ce qu’ajoute la preuve de processus avec v1.4.0 et ce qui est prévu. Les contrôles de politique, de personnes et physiques qu’aucun outil de code ne peut prouver sont listés aussi, pour qu’un résultat propre ne soit jamais lu comme plus qu’il n’est.

Des preuves pour chaque domaine d’audit de l’ingénierie

  • Gestion des changementsPrévu pour v1.4.0
  • Développement sécuriséActif aujourd’hui
  • Gestion des vulnérabilités et des dépendancesActif aujourd’hui
  • Accès au code et séparation des tâchesPrévu pour v1.4.0
  • Intégrité et conservation des preuvesActif aujourd’hui
Actif
Prévu pour v1.4.0
En appui
Prévu
Votre organisation
RéférentielCarte des contrôlesActifPrévu pour v1.4.0PrévuContrôles que le code peut prouverEn appui
SOC 2Critères Trust Services (2017)717151
+45 contrôles de politique, de personnes et physiques (61 au total). Aucun outil de code ne les prouve ; chaque rapport les liste.
ISO/IEC 270012022, Annexe A11510262
+65 contrôles de politique, de personnes et physiques (93 au total). Aucun outil de code ne les prouve ; chaque rapport les liste.
PCI DSSv4.010115261
+36 contrôles de politique, de personnes et physiques (63 au total). Aucun outil de code ne les prouve ; chaque rapport les liste.
FedRAMP ModerateRév. 5, NIST SP 800-53B14221374
+136 contrôles de politique, de personnes et physiques (177 au total). Aucun outil de code ne les prouve ; chaque rapport les liste.
HIPAA45 CFR partie 16480084
+30 contrôles de politique, de personnes et physiques (42 au total). Aucun outil de code ne les prouve ; chaque rapport les liste.
GDPRRèglement (UE) 2016/67930032
+35 contrôles de politique, de personnes et physiques (40 au total). Aucun outil de code ne les prouve ; chaque rapport les liste.
DORARèglement (UE) 2022/255420461
+20 contrôles de politique, de personnes et physiques (27 au total). Aucun outil de code ne les prouve ; chaque rapport les liste.

Toevan apporte des preuves pour des contrôles ; il ne les certifie jamais et ne prétend pas qu’un référentiel est couvert. Que les preuves suffisent relève du jugement de votre auditeur.

Ouvrir les cartes de contrôles

Le processus de votre organisation

Ce qu’un logiciel ne peut pas prouver reste à votre charge et à celle de vos autres outils. Chaque rapport le liste, pour qu’un résultat propre ne soit jamais lu comme plus qu’il n’est.

  • de la politique de l’organisation122
  • d’un processus opérationnel113
  • de la sécurité physique48
  • des contrats et des fournisseurs25
  • des personnes et des RH23
  • d’une procédure réglementaire23
  • d’une évaluation externe13

367 contrôles dans le catalogue

Sur la feuille de route

Prévu. Pas encore dans le produit.

  • DORA RTS sur la gestion du risque lié aux TICPrévuRèglement délégué (UE) 2024/1774Art. 17 gestion des changements TIC avec preuve de processus ; Art. 16 développement et maintenance avec preuve issue du code.
  • NIST SSDFPrévuSP 800-218 v1.1Pratiques de développement sécurisé, à partir des blueprints, des revues et des contrôles de dépendances.
  • SLSAPrévuSpécification v1 (OpenSSF)Volet source issu des branches protégées et de la revue à deux personnes ; provenance de build prévue.
  • OWASP Top 10Prévu2021Règles associées aux catégories vérifiables dans le code.
  • Règlement européen sur la cyber-résilience (Cyber Resilience Act)PrévuRèglement (UE) 2024/2847Composants, export SBOM et traitement des vulnérabilités.

Ce que reçoit votre auditeur

Votre auditeur

Teste les preuves au lieu de les croire sur parole.

Des fichiers à conserver, une vue en lecture seule pour l’audit, et les instructions pour tout vérifier lui-même.

Trois façons de les vérifier

  1. Dans son navigateur, sans outil ni accès au dépôt
  2. En regardant votre ingénieur exécuter les vérifications sur des échantillons qu’il choisit
  3. Sur sa propre machine, avec git, openssl et le vérificateur Toevan sur demande
Ouvrir l’exemple de rapportLire la FAQ des auditeurs
Actif aujourd’hui

Un rapport par référentiel

Pour toute période et tout dépôt : un PDF pour le dossier, plus un CSV des enregistrements pour les tests.

  • PDF
  • CSV
Actif aujourd’hui

La piste de preuves complète

Chaque résultat de code et chaque dérogation, rattachés à leur commit et à la version du jeu de règles en vigueur, et à partir de v1.4.0 chaque fusion, approbation et changement de règle.

  1. 4f2a9c1
  2. c81e07d
  3. 6b39f20
Prévu pour v1.4.0

Des instructions qui n’exigent aucun compte

Chaque enregistrement se vérifie hors ligne avec openssl, ou cosign v2, face aux clés publiées.

$ openssl dgst -sha256 -verify toevan.pub \
    -signature sig.der pae.bin
Verified OK
Prévu pour v1.4.0

Les changements de contrôles au fil de l’eau

Règles de revue désactivées, contournements d’administrateur et push directs, scellés quand ils se produisent, pour qu’un trou entre deux instantanés ne passe pas inaperçu.

19 sept. 14:02Exigence de revue désactivéeTrou ouvert

Actif aujourd’hui

Un accès en lecture seule pour les auditeurs

Un rôle Auditeur qui lit la piste de preuves, les exports et les rapports, et peut revérifier le registre. Il ne voit ni dépôt ni code.

  • Lecture seule
  • Piste de preuves
  • Exports
  • Rapports

Commencez gratuitement. Parlez-nous quand l’audit devient réel.

Chaque offre scelle les mêmes preuves et se vérifie de la même façon. Les offres diffèrent par le périmètre, les rapports, les workflows et l’endroit où Toevan s’exécute.

  • Free

    Pour un premier dépôt et un premier aperçu du gate.

    • Dépôts : jusqu’à 2 dans une organisation, 1 dans un compte personnel
    • Sièges : jusqu’à 3 dans une organisation
    • Piste de preuves scellée avec export
    • Gate de pull request et canvas d’architecture
    • Marketplace officielle de blueprints
    • Correctifs IA : 10 chaque mois
    Commencer gratuitement

  • Team

    Recommandé

    Tarifé par dépôt gouverné et facturé à l’année, pour les organisations de cinq à cent dépôts.

    • Dépôts : 5 à 100, tarifé par dépôt gouverné, facturé à l’année
    • Sièges : illimités
    • Référentiels : tous les référentiels
    • Deep Check : sous réserve d’usage raisonnable
    • Rôles par dépôt
    • Correctifs IA : inclus, sous réserve d’usage raisonnable
    • Rapports de conformité en CSV et PDF
    • SSO (SAML et OIDC), bientôt disponible

    Commencez par un pilote : un dépôt et un référentiel, sur un cycle d’audit.

  • Enterprise

    Plus de cent dépôts, ou des conditions sur mesure.

    • Dépôts : plus de 100
    • Déploiement self-hosted ou VPC privé, sur demande
    • Conservation des preuves : contractuelle
    • Support prioritaire
    • Conditions de volume

Il n’y a pas encore de tarif public. Team est tarifé par dépôt gouverné et facturé à l’année, et nous le convenons avec vous.

Les questions qu’on nous pose en premier

Des réponses directes sur le périmètre, le déterminisme et la destination de votre code.

Une question sans réponse ?

Périmètre et adéquation

3 questions
Faut-il remplacer Vanta, Kosli ou nos scanners ?

Non. Toevan fonctionne seul pour la couche de code, et aux côtés des outils que vous avez. Gardez vos scanners pour la profondeur ; les contrôles propres à Toevan donnent à chaque changement une base de référence et décident de la fusion selon vos règles. Les verdicts signés arrivent dans Kosli sous forme d’attestations, et les rapports de Toevan se joignent aux contrôles dans Vanta, Drata ou votre propre registre.

Ce que Toevan ajoute, c’est un enregistrement scellé, calculé à partir du changement lui-même : ce que fait chaque changement et, à partir de v1.4.0, son chemin du commit à la production, signé au moment des faits et vérifiable sans nous.

Un rapport au vert signifie-t-il que nous sommes en conformité ?

Non, et chaque rapport le dit. Toevan apporte des preuves pour les contrôles qui relèvent du code et, à partir de v1.4.0, de votre processus de changement. Il ne certifie jamais un contrôle et n’exprime aucun avis sur la conception ou l’efficacité de fonctionnement des contrôles. Les revues d’accès, la réponse aux incidents, les tests de résilience, le risque lié aux tiers et la gouvernance restent à votre processus, et chaque rapport liste exactement ce qu’il ne couvre pas.

Ne prenez-vous en charge que GitHub ?

GitHub aujourd’hui, via une GitHub App avec des check runs et des annotations de pull request. À partir de v1.4.0, il lit aussi les fusions, revues, changements de règles et déploiements en production au fil de l’eau. GitLab et Bitbucket sont sur la feuille de route. Si l’un des deux est votre point bloquant, dites-le-nous et il remonte dans la liste.

Comment ça tourne

3 questions
L’application des règles est-elle vraiment déterministe ?

Oui. Les contraintes des blueprints sont évaluées sur le graphe de dépendances sans modèle dans la boucle : même entrée, même verdict, à chaque exécution. L’IA sert à suggérer des correctifs et à expliquer les violations, jamais à décider si le code respecte les règles.

Notre code sort-il de notre périmètre ?

L’analyse, l’évaluation des blueprints, le gate de pull request et la signature des preuves s’exécutent sur l’infrastructure UE de Toevan, et votre code source n’en sort pas. Les contrôles de dépendances envoient des noms et des versions de paquets, sauf ceux que Toevan identifie comme privés, à des services publics comme OSV.dev. Les fonctions IA facultatives peuvent envoyer un contexte dérivé du code à un fournisseur de l’UE ou à votre propre clé de fournisseur. L’ancrage Rekor, intégré et sur adhésion de chaque organisation, ne publie que des hachages d’enregistrements. L’auto-hébergement est disponible sur demande. La déclaration complète figure sur la page Sécurité.

Que se passe-t-il quand le gate se trompe ?

Vous demandez une exception avec une justification, un périmètre et une durée. Le bon responsable la revoit, elle expire à l’échéance, et l’exception elle-même devient une preuve.

Apportez un dépôt et votre prochain audit.

Nous travaillons avec un petit groupe de design partners au second semestre 2026 : des équipes réglementées qui livrent du code assisté par IA, de la Series B aux grands groupes. Le premier cycle d’audit fait la preuve.

Réserver un pilote d’auditVoir un exemple de rapport
  • Un dépôt, un référentiel
  • Des preuves dès la première pull request
  • Vérifiable sans compte Toevan