Tiden : vérifier que le code IA répond aux exigences

À quoi sert Tiden, concrètement ?

Tiden aide une équipe de développement à vérifier qu’un agent de programmation a livré le comportement demandé. Ce service de Qase, Inc. rassemble spécifications produit, sessions d’agents, tests et éléments de décision pour la livraison.

Prenons une API qui doit refuser les requêtes au-delà d’un seuil et indiquer un délai de nouvelle tentative. Compiler le code ne démontre pas ces deux obligations. Tiden relie le comportement attendu aux tests qui l’étayent et fait ressortir les points encore sans preuve.

Une revue centrée sur le besoin et ses preuves

Tiden lit le code, cartographie les spécifications du produit et signale celles qui n’ont pas de test. Les spécifications restent modifiables en Markdown, avec sources, composants, priorités et historique. Le lecteur peut retrouver l’origine d’une règle et suivre son évolution.

La capture d’intention transforme les décisions prises dans une session d’agent en propositions sur une branche révisable. Le parcours présenté sur le site suit les promesses d’un contrat de travail. Une personne examine les changements de spécification et de test avant de les intégrer. Il faut donc toujours vérifier que les assertions correspondent au besoin métier.

Mettre en place une première vérification

Le guide de démarrage officiel permet de commencer sur un périmètre limité :

1. Créer ou rejoindre une organisation, puis créer un produit dans un espace de travail.
2. Installer la CLI sur macOS, Linux ou Windows. Exécuter tiden setup pour l’autorisation et l’association au dépôt, puis tiden config verify.
3. Connecter l’application GitHub de Tiden aux dépôts choisis en examinant les permissions.
4. Créer une spécification, éventuellement depuis un fichier Markdown, puis un test associé et ses résultats.
5. Lire Traceability : verified, not_run et no_test ne décrivent pas le même niveau de preuve.
6. Installer les hooks avec tiden intent install, vérifier leur état et relire les branches issues des sessions.

Un premier comportement observable suffit pour évaluer la pertinence du suivi avant d’étendre le modèle à tout le produit.

Décider d’une livraison avec les quality gates

Les contrôles combinent couverture des spécifications, résultats de test, risque par composant, fraîcheur des preuves et problèmes de production disponibles. Ils peuvent porter sur le produit principal, une branche ou une version. Le résultat indique un passage, un blocage ou une acceptation explicite du risque.

La commande tiden gate check --product-id <product-id> renvoie un code non nul en cas de blocage ou de risque encore à examiner. Le suivi des erreurs d’exécution relie aussi les incidents aux versions et environnements. Un verdict favorable reste lié aux exigences et contrôles configurés ; il ne garantit pas l’absence de tout défaut.

Essai, facturation et traitement des données

Au 15 octobre 2026, les prix publics mensuels en dollars sont de 49 USD pour Starter et 199 USD par produit pour Team. Starter inclut un produit, trois dépôts au maximum et 25 changements vérifiés par mois. Team inclut 100 changements par produit et des dépôts illimités, avec des frais d’usage supplémentaires possibles. Les deux proposent 14 jours d’essai ; la facturation commence au jour 15 si l’abonnement est conservé.

Un changement vérifié est une pull request fusionnée avec un quality gate réussi, facturée une seule fois. Les relances, changements échoués et commits de robots sont gratuits. Les preuves sont conservées trois mois sur Starter et douze sur Team. Consultez les tarifs et le calculateur officiels pour les paliers, la télémétrie et l’annuel ; il ne s’agit pas d’un prix final en euros.

L’application GitHub lit les dépôts autorisés ; contrôlez son périmètre et protégez les jetons API. Le hook beforeSend permet de filtrer la télémétrie. La politique de confidentialité doit être rapprochée du contrat : les documents publics examinés ne démontrent pas une garantie universelle de traitement uniquement local ou d’absence d’entraînement sur tout code client. L’auto-hébergement Enterprise est un supplément payant.

Pour quelles équipes et quels outils ?

Tiden convient aux développeurs, responsables QA et équipes techniques qui livrent régulièrement du code écrit par des agents. Le site cite Claude Code, Cursor, Copilot et Codex comme outils complémentaires.

La CLI, l’API REST publique et le serveur MCP local donnent accès aux spécifications, tests, branches et verdicts. La CLI et le serveur MCP doivent être mis à jour ensemble pour conserver la compatibilité des configurations. L’intérêt dépend d’exigences entretenues et de tests utiles : l’outil ne définit pas à la place de l’équipe un besoin ambigu.

Questions fréquentes

Tiden remplace-t-il la revue humaine ?

Non. Les agents proposent des branches ; une personne examine et fusionne les changements acceptés. Tiden apporte la traçabilité utile à cette décision.

Des tests au vert suffisent-ils à valider le besoin ?

Ils prouvent seulement ce qu’ils vérifient réellement. Il faut regarder leur lien aux spécifications, les manques de couverture et les résultats périmés.

Comment démarrer sur un dépôt existant ?

Créez un produit, autorisez le dépôt et configurez la CLI. Reliez ensuite une spécification à un test et examinez Traceability avant d’élargir le dispositif.

Ressources officielles

• Dépôt du serveur MCP : adaptateur et instructions de développement.
• Historique des mises à jour : évolutions récentes.
• Contacter Tiden : déploiement Enterprise et revue de sécurité.