Rapport vérifiable

Un résumé généré par IA vous demande une chose inconfortable : de lui faire confiance. Vous ne savez pas si cette phrase a vraiment été dite en réunion, qui l'a dite ni quand. Le rapport vérifiable d'Uttera change cela : au lieu d'un texte qu'il faut croire, elle produit un rapport qui se vérifie phrase par phrase. C'est notre service le plus distinctif.

L'idée est simple et délibérée : ce n'est pas nous qui décidons de la vérité —c'est à qui écoute d'en juger—. Ce que nous faisons, c'est ancrer chaque affirmation à l'enregistrement : nous la sortons avec sa citation littérale, le locuteur, le segment et la minute exacte, et nous indiquons si cette citation est mot pour mot dans l'audio. Vous apportez le jugement ; nous apportons d'où vient chaque phrase, de façon indiscutable.

À quoi ça sert

Toute situation où ce qui a été dit compte et où, plus tard, quelqu'un peut le remettre en question :

• Procès-verbaux de conseil et d'assemblée — ce qui a été convenu, ancré à qui l'a dit et quand.
• Expertise et contentieux — un enregistrement transformé en preuve que la partie adverse peut vérifier elle-même.
• Conformité et audit — déclarations et contrôles avec leur appui littéral.
• Due diligence — ce qui a été affirmé en réunion, traçable phrase par phrase.
• Procédures RH — entretiens et auditions avec une trace vérifiable.
• Journalisme — citations ancrées à la minute exacte de la source.
• Litiges avec clients ou fournisseurs — « cela a été dit » cesse d'être votre parole contre la leur.

Il convient d'être clair, dès le départ, sur ce qu'Uttera prouve de votre rapport —et ce qu'elle ne prouve pas—:

Le graphe de preuves

L'analyse est livrée sous forme de graphe de preuves (evidence_graph) : une liste de claims, les affirmations pertinentes de l'enregistrement. Chacune porte text, state (son état : déclaré, conditionnel, contesté… — la liste complète ci-dessous), speakers, entities, un éventuel depends_on (de quelle autre affirmation elle dépend) et un tableau evidence avec les passages qui l'étayent (segment_id, t_start/t_end, quote et grounding).

Chaque affirmation est classée sur deux axes, pour savoir d'un coup d'œil ce que c'est et combien ça pèse.

Ce que c'est — le type :

• Décision — quelque chose qui a été décidé.
• Engagement — quelque chose à quoi quelqu'un s'est engagé, avec son responsable et, s'il y a lieu, son échéance.
• Chiffre — un nombre : un montant, un délai, une quantité, un pourcentage.
• Risque — un risque signalé.
• Question — une question restée en suspens.
• Contradiction — deux choses dites qui ne concordent pas.
• Affirmation — toute autre affirmation pertinente.

Combien ça pèse — l'état :

• Déclaré — affirmé de façon explicite.
• Conditionnel — dépend d'une condition, que le graphe indique à part.
• Inféré — déduit de l'échange ; non ancré comme vérifié.
• Contesté — les présents ne sont pas d'accord.
• Non résolu — resté en suspens, non tranché.

Ce grounding est l'ancrage de chaque citation, et nous le disons sans fard :

🔴 Ancrer, ce n'est pas juger de la vérité. Le graphe dit qui a dit quoi et où, et que la citation est vraiment dans l'audio. Il ne dit pas que ce qui a été dit est vrai : cela —et l'exactitude de la transcription— revient à qui écoute. C'est la même distinction qu'à Vérifier : authenticité et ancrage ne sont pas véracité.

Les chiffres du rapport concordent avec ce qui a été dit

Un compte rendu vaut par ses chiffres : un montant, un délai, une quantité, un pourcentage. C'est pourquoi, lorsqu'une affirmation porte un chiffre, le rapport le confronte à la citation littérale dont il provient. Si le nombre du rapport n'apparaît pas dans ce qui a été dit, il est signalé —il n'est pas laissé passer comme s'il était étayé—.

Deux niveaux de vérification

Tous les rapports n'exigent pas la même rigueur. Il y a donc deux niveaux :

Forensique : bientôt disponible pour les plans supérieurs.

Comment la demander

Par l'API, c'est le service de résumé avec ?mode=intelligence (et, pour fixer le type de rapport, report_schema/report_prompt). Ajoutez ?report=pdf pour le PDF signé : le graphe déjà validé est à l'intérieur du document, couvert par sa signature, de sorte que le PDF suffit à le vérifier. Le PDF arrive dans report.pdf_base64 avec ses signatures (content_signature, container_signature, pdf_sha256, key_fingerprint). La facturation se fait au token, comme le résumé ; une affirmation unverified n'est pas facturée à part ni vendue comme vérifiée.

curl -X POST "https://api.uttera.ai/v1/summarize?mode=intelligence&report=pdf" \
  -H "Authorization: Bearer $UTTERA_API_KEY" \
  -F "file=@reunion.mp3" \
  | jq -r '.report.pdf_base64' | base64 -d > rapport.pdf

Sans programmer, dans le Studio : cochez la case « Rapport vérifiable », choisissez la langue de sortie et exécutez ; le graphe s'affiche à l'écran et vous pouvez le télécharger (JSON) à côté du PDF.

Vérifier un rapport

Chaque rapport PDF que nous émettons est signé cryptographiquement. N'importe qui —vous, votre client, l'autre partie d'une négociation— peut vérifier qu'un rapport vient de nous et que personne n'y a touché en chemin, sans nous demander la permission et sans compte.

Le plus rapide est la page. Sur uttera.ai/fr/verify, vous téléversez le PDF et c'est tout : il n'y a rien à copier ou coller, parce que la signature voyage à l'intérieur du fichier lui-même. C'est prévu pour quiconque reçoit un rapport et ne va pas écrire de code — un avocat, un expert, la partie adverse. Le reste de ce chapitre est pour le faire vous-même, avec curl ou sans passer par nous.

🔴 L'authenticité n'est pas la vérité. Vérifier un rapport vous dit d'où vient le document et que personne ne l'a modifié. Cela ne dit pas que ce qu'il dit est vrai. Le rapport est généré à partir d'un enregistrement fourni par le client, et tant l'exactitude de la transcription que la véracité de ce qui y est dit sont de sa responsabilité. Uttera n'a pas été témoin de ce qui a été enregistré, ne le vérifie pas et ne le certifie pas.

Ce que c'est et ce que ce n'est pas. C'est une signature d'authenticité cryptographique utilisant Ed25519. Ce n'est pas une signature électronique qualifiée au sens du règlement eIDAS : elle prouve que le document est sorti de notre système et n'a pas changé, elle n'est pas l'équivalent d'un certificat d'un prestataire qualifié. Nous le disons ici, et le rapport le dit aussi.

Pourquoi il y a deux signatures

Chaque rapport en porte deux, et chacune répond à une question différente :

Celle du contenu est imprimée à l'intérieur du rapport, dans le pied de chaque page, comme une courte empreinte. Celle du conteneur ne peut pas aller à l'intérieur —signer quelque chose qui est ensuite modifié est impossible— elle est donc ajoutée après le document fini, sur une ligne à la fin du fichier commençant par %%UTTERA-FIRMA-V1:. Un lecteur de PDF ne la voit jamais : le format dit de lire à partir du dernier startxref, donc tout ce qui suit le %%EOF est ignoré.

C'est ce qui fait que le PDF seul suffit pour vérifier les deux signatures. Auparavant, elle était renvoyée séparément par l'API et il fallait la garder à côté du fichier : dès que quelqu'un transférait le rapport par e-mail, la signature restait en arrière et le document ne pouvait plus être vérifié du tout. L'API la renvoie toujours dans report.container_signature pour quiconque préfère l'archiver séparément.

La clé publique

Nous la publions à trois endroits, et les trois donnent la même chose :

https://uttera.ai/.well-known/uttera-firma.pub     le PEM, seul
https://uttera.ai/.well-known/uttera-firma.json    chaque clé, avec ses dates
https://api.uttera.ai/v1/reports/public-key        celle qui signe en ce moment

La chaîne de confiance est la même qu'utilisent les jeux de clés DKIM ou JWKS : le certificat TLS d'uttera.ai atteste que le domaine est le nôtre, et ce domaine publie la clé. Vous n'avez pas à nous croire sur parole au téléphone.

Le vérifier depuis la ligne de commande

Le endpoint est public et ne prend aucune clé d'API :

POST https://api.uttera.ai/v1/reports/verify

Avec le PDF et rien d'autre. C'est le mode normal : la signature est dans le fichier, donc rien que vous auriez dû garder séparément n'est nécessaire. Il vérifie les deux signatures d'un coup :

curl -s -X POST https://api.uttera.ai/v1/reports/verify \
  -H "Content-Type: application/json" \
  -d "{\"modo\":\"pdf\",\"pdf_b64\":\"$(base64 -w0 report.pdf)\"}"

{"mode": "pdf", "signed": true,
 "valid_container": true, "valid_content": true,
 "key_fingerprint": "56ac333b…",
 "fields": {"cliente": "…", "titulo": "…", "generado": "1789641036", …}}

Les deux à true, c'est le bon cas. valid_content vrai avec valid_container faux signifie que le texte est le nôtre mais que le fichier a été réenregistré — tout outil PDF qui l'ouvre et l'écrit change les octets — ce qui n'est pas la même chose qu'un faux. signed faux signifie que le fichier ne porte aucune signature de nous, ou qu'elle a été retirée.

Les deux modes ci-dessous sont pour quand vous détenez les pièces séparément : un rapport plus ancien, ou une signature archivée à part.

Vérifier le fichier (signature du conteneur). Il vous faut le PDF et la signature qui l'accompagnait dans report.container_signature :

curl -s -X POST https://api.uttera.ai/v1/reports/verify \
  -H "Content-Type: application/json" \
  -d "{\"modo\":\"contenedor\",
       \"pdf_b64\":\"$(base64 -w0 report.pdf)\",
       \"firma_b64\":\"THE_CONTAINER_SIGNATURE\"}"

{"valid": true, "mode": "contenedor", "key_fingerprint": "56ac333b…"}

Vérifier le contenu. Il vous faut la réponse d'analyse exactement telle que nous l'avons renvoyée, plus report.content_signature et la date de report.generated_unix — le timestamp unix, qui est la valeur qui a été signée ; generated_at est la date écrite, pour la lecture. Le timestamp est imprimé sur le rapport lui-même, à côté du numéro :

curl -s -X POST https://api.uttera.ai/v1/reports/verify \
  -H "Content-Type: application/json" \
  -d '{"modo":"contenido",
       "datos": { …la réponse de /v1/summarize… },
       "cliente":"Meridiano Asesores, S.L.",
       "titulo":"Compte rendu de la réunion",
       "generado":1789639533,
       "firma_b64":"THE_CONTENT_SIGNATURE"}'

Nous ne stockons rien pour cela. Vérifier est une opération à clé publique sur ce que vous nous envoyez : nous ne consultons rien. C'est pourquoi cela fonctionne sur un rapport d'il y a des années, et pourquoi nous ne pouvons pas vous dire combien de rapports nous avons émis ni en retrouver un que vous avez perdu.

Rotation des clés

Chaque clé est utilisée pendant douze mois, et est remplacée plus tôt au moindre soupçon. Les clés retirées restent publiées pour toujours : un rapport signé aujourd'hui doit être vérifiable dans dix ans.

C'est pourquoi chaque rapport porte, à côté de sa signature, l'empreinte de la clé qui l'a signé. Le vérificateur sait laquelle utiliser sans les essayer toutes.

Si nous devions un jour retirer une clé parce qu'elle a été compromise, nous le dirions ici avec la date. Et nous dirions aussi la partie inconfortable : les rapports signés avec elle cessent de prouver quoi que ce soit, parce que celui qui détenait la clé aurait pu signer des documents antidatés.