Tusk
Tusk AI, Inc. · Programmation · Productivité
Tusk est un agent de test IA qui écrit et exécute des tests unitaires et d'API sur chaque pull request, puis signale les défauts trouvés. Tusk AI, Inc. a arrêté le produit le 10 juin 2026.
À propos de Tusk
What Is Tusk
Tusk est né en 2024 dans la promotion W24 de Y Combinator avec une promesse étroite. Vous confiez au agent les bugs remontés par vos clients, vous récupérez une pull request. Dans une petite équipe, une correction de dix lignes peut coûter une après-midi entière, et Tusk servait justement à sortir ces tickets du planning.
En 2026, le produit était devenu un agent de test IA. Il générait des tests unitaires et d'API pour chaque pull request, les lançait lui-même et recommençait jusqu'à ce qu'ils passent. Tester reste la partie de la mise en production pour laquelle personne n'a de temps, et Tusk se vendait comme le collègue qui s'en charge sans qu'on le demande.
Les limites comptent si vous évaluez ce qu'il laisse derrière lui. Il fallait un dépôt GitHub, une suite de tests existante et de la patience, car l'agent relançait plusieurs fois un test en échec. Ses chiffres sur la détection des cas limites venaient de ses propres benchmarks, jamais d'un audit indépendant.
La vraie limite est une date. Tusk AI, Inc. a annoncé le 11 juin 2026 que le produit avait été arrêté la veille. La GitHub App a été retirée des organisations clientes, les utilisateurs de Tusk Drift ont dû désinstaller le SDK et supprimer le workflow de CI, et le support a répondu pendant un mois. L'entreprise oriente vers Devin, de Cognition, pour l'automatisation des tests et la revue de code.
Getting Started
- Créer un compte Tusk et installer la GitHub App sur les dépôts que l'agent pouvait lire et modifier.
- Installer la CLI à la racine de chaque service, une seule commande suffisait, puis lancer la configuration initiale pour que Tusk indexe vos conventions de test.
- Ouvrir une pull request comme d'habitude. Tusk publiait les tests générés en commentaire, les exécutait dans votre CI et corrigeait ceux qui échouaient.
- Relire ces tests comme n'importe quel code. L'entreprise annonçait qu'environ 69 % des tests produits finissaient fusionnés dans les pull requests.
Informations sur le produit
Aperçu des tarifs, des plateformes compatibles et des performances de Tusk.
Idéal pour
Les utilisateurs, tâches et cas d'usage où cet outil convient le mieux.
Utilisateurs
- Petites équipes sans profil QA dédié
- Fondateurs qui relisent encore le code
- Ingénieurs backend et plateforme
Tâches
- Remonter la couverture avant une sortie
- Détecter les régressions dans les pull requests
- Surveiller les contrats d'API tierces
Cas d'usage
- Un code historique peu couvert et sans budget de réécriture
- Une équipe qui déploie plusieurs fois par jour sur trois ou quatre dépôts
- Comparer des outils qui n'existent plus
Fonctionnalités clés
Des tests unitaires pour chaque pull request
Tusk lisait le diff, allait chercher du contexte dans vos tests existants et proposait des tests unitaires en commentaire de la pull request. Il exécutait ce qu'il écrivait et reprenait les échecs, si bien que la sortie était du code exécutable et non une suggestion. Pour une équipe qui voyait les tests comme une corvée, obtenir des tests qui tournent sans ouvrir l'éditeur constituait toute la valeur.
Des tests d'API tirés du trafic réel
Tusk Drift enregistrait le trafic réel sur vos endpoints et le transformait en tests d'API. Au lieu d'écrire des mocks, vous obteniez des tests issus de ce que le service recevait vraiment. Cela servait à surveiller les contrats, là où une réponse modifiée en silence casse des appelants dont on n'entend parler qu'au moment d'une réclamation.
CoverBot complète la couverture selon un calendrier
CoverBot fonctionnait comme Dependabot, sauf que ses pull requests contenaient des tests unitaires au lieu de montées de version. Vous le pointiez vers un dépôt, choisissiez un rythme quotidien ou hebdomadaire, et le laissiez tourner. Tusk parlait de 30 % de couverture gagnée en un mois, un chiffre maison à lire comme une tendance, pas comme une garantie.
Des suites qui s'entretiennent seules
Les tests vieillissent quand la logique métier bouge. Tusk mettait à jour les suites en échec à chaque commit pour qu'elles collent au comportement courant. C'est à la fois pratique et risqué, car un test qui se réécrit pour passer peut aussi se réécrire par-dessus un vrai bug.
Le contexte de Jira, Linear et de vos tests
Tusk tirait le contexte métier des tickets Jira et Linear, et les patrons de code de vos tests existants. Les tests générés suivaient vos conventions de nommage et de fixtures au lieu d'inventer un style. Les équipes qui avaient essayé des générateurs génériques citaient souvent cette différence en premier.
Revue de code et correction de bugs
L'agent d'origine n'a jamais totalement disparu. Tusk relisait les pull requests et pouvait remonter d'un bug signalé jusqu'au correctif. La revue venait avec le même avertissement que les tests : tout ce qui est généré demande une relecture humaine avant fusion.
Avantages et inconvénients
Avantages
- Les tests arrivaient déjà exécutés, ce qui supprimait les allers-retours habituels des copilotes IA.
- Le générateur de tests unitaires s'intégrait à la CI, donc la couverture progressait sans sprint dédié.
- Les intégrations GitHub, Jira et Linear gardaient le contexte dans les outils que l'équipe utilisait déjà.
- Le tarif par développeur actif, sans minimum de licences, rendait l'essai peu coûteux sur un seul dépôt.
Inconvénients
- Le produit n'existe plus. Les dépôts ont perdu la GitHub App et les utilisateurs de Drift ont dû retirer du code SDK de leurs services.
- Les benchmarks venaient de l'entreprise, donc l'affirmation sur les cas limites ignorés par les autres agents n'a jamais été vérifiée de l'extérieur.
- Le meilleur résultat supposait une suite existante et une seule plateforme. Hors GitHub, ou sans tests au départ, le rendement chutait nettement.
- Une revue par IA demande toujours un œil humain, et un test qui passe ne prouve pas que le code est juste.
Questions fréquentes
Tusk générait des tests unitaires et d'API pour les pull requests, relisait le code et corrigeait les bugs signalés par les clients. Les équipes s'en servaient pour remonter la couverture et repérer les régressions avant déploiement.
Contenus associés
Découvrez des outils, des compétences et des articles liés à Tusk.
Alternatives à Tusk
Base Code
Base44 (Wix) · Programmation · ProductivitéBase Code est un environnement de développement cloud partagé signé Base44. Votre équipe décrit des modifications sur un dépôt GitHub dans le chat, les vérifie en aperçu et les renvoie sous forme de pull requests.
Google EmbeddingGemma 2
Google DeepMind · Rédaction · Image · ProgrammationGoogle EmbeddingGemma 2 est un modèle ouvert de 740 millions de paramètres qui transforme texte, code, images, audio et images vidéo en vecteurs d'un même espace de 768 dimensions, sur un téléphone ou un ordinateur portable.
GitGlow
GitGlow · Programmation · ProductivitéGitGlow est un client Git de bureau qui place votre code et les modifications de vos agents IA dans une même revue, pour savoir ce qui quitte votre machine avant de livrer.