veilletech.frCe qui se passe
Chez Linear, les agents écrivent désormais la majorité des tests, et l'équipe en ajoute environ 2 000 par semaine. La suite a presque quadruplé depuis janvier ; la CI, elle, coûtait cher et ralentissait. Le billet publié le 21 septembre 2026 détaille le chantier. Bilan : une pull request attend un peu plus de 5 minutes au lieu de plus de 6, et le temps machine par test a été divisé par deux environ. Sans ce travail, la suite prendrait aujourd'hui autour de 11 minutes. La base de code est surtout en TypeScript, mais la plupart des leviers valent pour d'autres piles.
Les leviers, chiffrés
Outillage.
- Runners tiers à la place de ceux de GitHub Actions : −34 % en moyenne sur
les tâches, −52 % sur
tsc, à pipeline identique. tsgo, le compilateur TypeScript natif : −73 % sur la médiane hebdomadaire de la vérification de types.- Règles ESLint maison réécrites sur l'arbre syntaxique, sans information de type : −68 % sur le lint de l'API, −55 % sur le dépôt entier — et un passage à Oxlint facilité.
Tâches sur le chemin critique. Les petites tâches de détection de changements précèdent tout le reste : aucun des huit shards de tests ne démarre avant elles.
- Checkout à profondeur limitée : la plus lente passe de 94 à 20 s ; médiane de 26 à 8 s, p90 de 31 à 12 s.
- Checkout remplacé par une action maison avec reprises et
GIT_HTTP_LOW_SPEED_LIMIT/GIT_HTTP_LOW_SPEED_TIME: une connexion bloquée abandonne au bout d'environ 30 s au lieu de pendre. - L'écriture des marqueurs de cache sortie du chemin de fusion : 42 s gagnées par pull request.
Préparation répétée.
- Client Postgres préinstallé dans une image de CI : 7 à 8 s de moins par shard.
- Installation limitée au paquet API du monorepo pnpm : 44-73 s → 16-18 s.
- Pas de cache
node_modules: sa restauration prenait 28 s, contre 7,5 s pour une installation filtrée. - Instantané du schéma au lieu de rejouer les migrations : 12 s → 1-2 s par conteneur.
- Sept contrôles regroupés en deux tâches : 87 000 minutes de runner par mois, soit 11,8 % de la consommation.
Ensemble, préparation par shard ramenée de 110-140 s à 67-73 s, puis autour de 40 s.
Exécution des tests. Vitest répartit par fichier, pas par durée : les gros
fichiers ont été découpés, et le passage de quatre à huit shards a rendu la
tâche critique 19 % plus rapide et 19 % moins chère. Le gain le plus fort vient
d'un projet Vitest avec isolate: false, qui évite de reconstruire le graphe
d'entités, GraphQL et décorateurs dans chaque fichier : environ 17 %
d'économie mensuelle, shard le plus lent de 300-379 s à ~195 s.
Ce que ça change
Deux enseignements dépassent le cas de Linear. D'abord, multiplier les shards
ne paie que si le coût fixe par shard est bas : à 110-140 s de préparation,
huit shards auraient passé 15 à 19 minutes rien qu'en installation. Ensuite,
l'optimisation la plus rentable était aussi la plus risquée. isolate: false partage l'état entre fichiers ; Linear n'y admet un fichier que sur
commentaire explicite, a ajouté le nettoyage nécessaire, a laissé de côté ceux
qui utilisent des timers simulés — et a mis à jour les skills de ses agents
pour que les tests générés respectent ces contraintes par défaut.
Source : AI coding has made CI a bottleneck, so we reworked ours to keep up, Linear, 21 septembre 2026.