API du détecteur SynthID : ce que les développeurs peuvent construire

Vous construisez une file de modération, un outil d’introduction en salle de rédaction ou un panneau de provenance pour les téléchargements de clients. Vous tapez « API du détecteur SynthID » car une API rendrait le produit propre : télécharger un fichier, recevoir une réponse approuvée par Google, afficher le résultat. À ce jour, Google n’a pas publié d’API de détection SynthID publique générale permettant à tout développeur tiers de soumettre des fichiers arbitraires et de recevoir des résultats officiels SynthID.

Cela ne signifie pas qu’il n’y a rien à construire. Cela signifie que la limite doit être visible dans le produit. Vous pouvez vérifier des identifiants ouverts. Vous pouvez inspecter les métadonnées. Vous pouvez orienter les utilisateurs vers la route officielle SynthID quand la question est spécifique à Google. Ce que vous ne devriez pas faire, c’est envelopper des vérifications sans rapport dans un langage SynthID et espérer que les utilisateurs ne remarqueront pas la différence.

Ne construisez pas autour d’un endpoint non officiel

Les résultats de recherche et les sites d’hébergement de code peuvent contenir des wrappers, des expériences, des tentatives de rétro-ingénierie ou des bibliothèques pour des projets de filigrane différents. Traitez-les comme des recherches à moins qu’ils ne soient clairement liés à une prise en charge officielle de Google. Un script qui lit les métadonnées n’est pas une API SynthID. Un classificateur qui devine si une image semble générée n’est pas un décodeur de filigrane. Un endpoint privé découvert via une application web n’est pas un contrat public stable pour votre produit.

Le risque pratique est évident. Si votre fonctionnalité dépend d’une route non officielle, elle peut casser sans préavis. Pire encore, vos utilisateurs peuvent croire qu’ils voient un résultat officiel quand ce n’est pas le cas. L’UX de provenance, c’est l’UX de confiance. Les étiquettes comptent autant que le code car l’étiquette indique à l’utilisateur jusqu’où les preuves vont.

Construisez d’abord un chemin de vérification C2PA

Les identifiants de contenu C2PA sont un meilleur point de départ pour les développeurs car ils sont conçus pour être vérifiés en dehors du détecteur privé d’un seul fournisseur. Un fichier peut porter un manifeste signé qui enregistre des affirmations sur l’origine, les retouches, les outils ou le contexte de publication. Votre application peut inspecter ce manifeste avec une bibliothèque C2PA open source, valider les signatures et présenter le résultat d’une manière compréhensible pour un utilisateur.

Gardez la sortie précise. « Identifiant présent. » « Signature valide. » « Impossible de valider le manifeste. » « Aucun identifiant C2PA trouvé. » Chacune de ces déclarations concerne la vérification que vous avez effectuée. Si vous avez besoin d’une référence produit, notre vérificateur d’identifiants de contenu montre le type de limite qui compte : il vérifie l’identifiant ouvert au lieu de transformer le résultat en une affirmation d’autorité universelle.

Ajoutez l’inspection des métadonnées sans les surfacturer

Les métadonnées valent également la peine d’être exposées, notamment pour les images et les documents qui portent toujours des champs EXIF, XMP, IPTC ou de logiciel. Une couche de métadonnées peut afficher des détails d’appareil, des applications de retouche, des horodatages ou des étiquettes descriptives. Elle peut aussi être absente, obsolète, trompeuse ou dépouillée par des flux de partage ordinaires. Pour cette raison, les métadonnées doivent être traitées comme un contexte, pas comme une preuve.

Une interface adaptée aux développeurs peut afficher les champs bruts pour les utilisateurs experts et un résumé simple pour tous les autres. Ajoutez un lien vers une explication des limites. Si vous voulez voir comment nous présentons cette distinction, comparez la visionneuse de métadonnées avec la vue d’ensemble des détections. Le même fichier peut porter des métadonnées utiles, des identifiants valides, les deux ou aucun.

Proposez une redirection vers l’outil officiel pour SynthID

Quand un utilisateur demande spécifiquement à propos du filigrane Google, la démarche honnête pour un produit est une redirection. Expliquez que la détection SynthID doit passer par la route officielle de Google, puis fournissez le lien ou les instructions sans impliquer que votre application a effectué cette détection. Vous pouvez rendre le flux de travail plus fluide en conservant le fichier original, en rappelant aux utilisateurs la confidentialité et en leur donnant un endroit pour enregistrer le résultat officiel manuellement.

Un bon texte d’interface pourrait dire : « Cette application ne lit pas SynthID. Pour le filigrane de Google, utilisez le SynthID Detector officiel. Vous pouvez toujours vérifier les identifiants C2PA et les métadonnées ici. » Cette phrase n’est pas évasive. Elle dit la vérité au moment où la confiance est la plus fragile. Si votre public inclut des équipes de conformité ou des éditeurs, ils préféreront cette clarté à un faux positif spectaculaire.

Codes d’état qui vous protègent

Renvoyez des états qui correspondent à vos vérifications réelles. Pour C2PA, utilisez des catégories telles que valide, invalide, absent, non pris en charge et erreur. Pour les métadonnées, utilisez trouvé, non trouvé, non pris en charge et échec d’analyse. Pour SynthID, à moins que vous n’ayez un mécanisme officiel, utilisez non vérifié ici et ajoutez un lien vers Google. Évitez « propre », « humain », « faux » ou « sans IA ». Ces mots prétendent plus que les signaux sous-jacents ne peuvent le supporter.

Si vous stockez des fichiers, documentez la rétention et la suppression. Si vous traitez localement, dites-le clairement et évitez d’impliquer que chaque opération reste dans le navigateur à moins que ce ne soit vrai. Si vous prenez en charge des téléchargements d’entreprise, séparez l’examen de sécurité de l’examen de provenance. Un fichier peut être sûr à manipuler et avoir une origine inconnue, ou porter une provenance et contenir des informations sensibles.

Le chemin de développement utile n’est pas bloqué par le manque d’API de détection SynthID publique. Il est simplement plus étroit que la phrase de recherche ne le suggère. Construisez les parties qui sont ouvertes, étiquetez les parties qui ne le sont pas et faites de la redirection officielle Google une partie du parcours utilisateur plutôt que de prétendre qu’elle s’est produite dans votre code.