Story
Comment un agent IA de QA tourne sur un seul Mac mini
1 792 tests cassés, un Mac mini et un agent doté de 24 outils. Comment l'agent QA de PerfectApps répare les tests, trie les échecs et valide les releases, et pourquoi il tourne sur Apple silicon plutôt que sur un VPS Linux.
Mis à jour le 2026-09-15
PerfectApps est une plateforme d'applications no-code. Son équipe QA gère plus de 2 100 cas de test automatisés en Cypress et Selenium. Aujourd'hui, l'essentiel de ce travail est lancé, analysé et rapporté par un agent IA qui vit sur un seul Mac mini dédié.
Voici comment il est né, ce qu'il fait, et pourquoi le choix du matériel était délibéré.
Tout a commencé avec 1 792 tests cassés
Un correctif de sécurité obligatoire a retiré Bootstrap de tout le code de PerfectApps. La structure des pages a changé partout en même temps, et 1 792 cas de test ont cassé le même jour, dans plus de 50 zones du produit.
Personne n'a estimé la réparation manuelle en détail, parce qu'elle n'a jamais été faite à la main. L'estimation grossière : toute l'équipe, quatre personnes, uniquement là-dessus, pendant deux mois au plus.
C'est là que l'agent a cessé d'être une idée.
Réparer, puis couvrir, puis juger
Réparer. Au lieu de corriger 1 792 tests un par un, l'agent a trouvé chaque cause racine une seule fois et appliqué le correctif à toutes les specs concernées. La connexion a été déplacée dans une seule commande partagée, pour qu'une modification atteigne tous les tests.
Couvrir. Une fois la réparation au point, la même approche s'est attaquée aux zones jamais testées. La suite est passée de 1 400 à 1 955 fichiers de spec. Parmi elles, un éditeur visuel de diagrammes dessiné sur un canvas, qui n'offre rien sur quoi un test puisse cliquer. La réponse a été d'arrêter de tester le canvas et de vérifier plutôt les données enregistrées : 51 nouvelles specs, toutes au vert dès le premier passage complet.
Juger. Après chaque régression, quelqu'un devait passer les échecs en revue et décider lesquels étaient des tests cassés, lesquels de vrais bugs et lesquels du bruit. Cela prenait 12 heures à trois personnes par release. C'est maintenant le travail de l'agent. Sur une release, il a passé en revue 1 748 résultats de test et trouvé exactement un vrai bug produit parmi environ 300 échecs. Le reste était de la dette de migration.
Ce que fait l'agent
L'agent dispose de 24 outils et décide lui-même lesquels appeler et dans quel ordre. L'équipe lui parle en anglais courant, dans Microsoft Teams ou sur le web.
Une release passe par un pipeline fixe :
One release run
- 1SanityA smoke test on production. If it fails, everything stops.
- 2RegressionMore than 2,100 test cases in five parallel lanes, in about 90 minutes.
- 3New testsSpecs for areas without coverage, generated while regression runs.
- 4TriageEvery failure classified as a test issue, a real bug, a flaky test or a known blocker.
- 5ReportA GO or NO-GO verdict, posted to Teams and to the GitHub pull request.
Quelques exemples de ce qui a changé :
| Tâche | À la main | Avec l'agent |
|---|---|---|
| Trier une régression complète | 12 heures, 3 personnes | Quelques minutes |
| Écrire un nouveau test à partir d'un ticket Jira | 2 à 4 heures chacun | Quelques minutes |
| Ouvrir un bug après une régression, avec les preuves | 30 à 60 minutes chacun | Automatique |
| Valider une release de hotfix | Une demi-journée | Quelques minutes |
La valeur n'est pas le temps gagné sur une ligne en particulier. C'est que des semaines de travail manuel n'apparaissent plus du tout dans le cycle de release.
Pourquoi un Mac mini, et pas un serveur Linux
L'agent tourne en natif sur un Mac mini dédié. Pas de Docker, pas de Kubernetes, pas de cluster. Il communique avec l'extérieur par un Cloudflare Tunnel.
C'était une décision, prise après comparaison avec un VPS Linux :
- Les navigateurs tournent plus vite. Sur Apple silicon, Chrome et Cypress tournaient trois à cinq fois plus vite que sur le VPS.
- L'agent travaille sur le vrai dépôt. Il lit et écrit directement les fichiers de test, donc générer une nouvelle spec ne demande aucune couche d'API supplémentaire.
- Rien à simuler. Un Mac a une vraie pile d'affichage, donc pas de serveur d'affichage virtuel à maintenir en vie juste pour ouvrir un navigateur.
- De la place pour des modèles locaux. De petits modèles sur le Neural Engine du Mac peuvent gérer l'aiguillage et la classification simple, et le modèle cloud plus grand est réservé au raisonnement qui en a besoin.
Le VPS aurait coûté 43 dollars de moins par mois. C'est moins que la journée d'ingénierie qu'il faudrait pour migrer.
Ce que cela veut dire si vous construisez un agent
- Donnez à l'agent sa propre machine. Il lui faut un navigateur, un système de fichiers et la liberté de tourner pendant des heures sans que personne ne le déconnecte ou ne le redémarre.
- Commencez par le travail dont personne ne veut. Le tri et la réparation des tests étaient le goulot d'étranglement, pas l'écriture de nouvelles fonctionnalités.
- Gardez une personne sur le verdict. L'agent classe et recommande. L'équipe décide si une release part.
- Choisissez le matériel selon la charge de travail. Si votre agent pilote un navigateur ou compile pour les plateformes Apple, Apple silicon est vite rentabilisé.
L'agent QA de PerfectApps a été construit pour un usage interne et tourne sur un Mac mini dédié chez MacDuty.
En stock aujourd'hui
Ceux-ci sont en baie maintenant. Choisissez-en un, voyez ce qu'il comprend, et créez votre compte seulement au moment de commander.
Vérification des baies
Un Mac mini à vous
Choisissez une configuration. Si elle n'est pas disponible, laissez votre e-mail et nous vous écrivons le jour où elle est en baie.
À l'année : au moins 19 % de moins qu'au mois
À suivre