AI Usage Patterns : Ce que révèlent 6 ans de données de développement
Photo by cottonbro studio
Introduction : le grand saut des PRs
Linear, l'outil de gestion de projet utilisé par des milliers d'équipes tech, a publié une analyse fascinante de 6 ans de données d'usage. Le chiffre qui a fait réagir toute la communauté dev : les pull requests ont augmenté de 111 % en deux ans.
Pas 20 %, pas 50 %. Plus du double. Et ça ne concerne pas que les ingénieurs. L'analyse de Linear, titrée "AI usage patterns in software teams", montre que l'adoption de l'IA a pénétré toutes les fonctions d'une organisation produit — du fondateur au designer en passant par le support client.
Mais le diable est dans les détails. Si les PRs explosent, le temps passé sur les projets livrés, les demandes clients et la documentation, lui, est resté stable. Alors, l'IA rend-elle vraiment les équipes plus productives ?
Ce que disent les données (et ne disent pas)
Les PRs doublent, mais pas les livrables
Le chiffre le plus frappant est cette augmentation de 111 % du volume de pull requests. À première vue, c'est la preuve que l'IA accélère massivement la production de code.
Mais en regardant de plus près, les métriques de livraison — projets terminés, features livrées, tickets résolus — n'ont pas suivi la même courbe. Les équipes écrivent deux fois plus de code qu'avant, mais ne livrent pas deux fois plus.
C'est cohérent avec ce qu'on observe sur le terrain :
- L'IA génère du code plus vite, mais ce code doit être reviewé, testé, et souvent réécrit partiellement
- Les PRs deviennent plus petites et plus fréquentes, pas plus impactantes
- Le temps gagné en écriture est réinvesti en relecture et correction
L'adoption partout, mais pas par tout le monde pareil
Linear a croisé ses données par fonction et par rôle. Résultat : les fondateurs et CEOs sont en tête de l'utilisation de l'IA, suivis par les ingénieurs, puis les designers et le produit.
C'est un signal intéressant. D'un côté, ça montre que l'IA est perçue comme un levier stratégique au plus haut niveau. De l'autre, ça pose la question : est-ce une adoption organique (les fondateurs y trouvent un vrai gain) ou descendante (ils poussent l'outil dans l'équipe) ?
Plusieurs commentateurs sur Hacker News ont noté ce biais : "Les fondateurs en tête du classement d'usage en dit plus sur la pression hiérarchique que sur la valeur réelle."
L'IA change l'exécution, pas la décision
L'un des enseignements les plus importants de l'étude : le temps passé sur les décisions produit et la stratégie n'a pas changé. L'IA a modifié comment les équipes exécutent, mais pas quoi elles décident de construire.
C'est une distinction cruciale pour les fondateurs de SaaS. L'IA ne remplace pas la réflexion produit — la spécification, la priorisation, la compréhension du marché. Elle rend juste l'exécution plus rapide.
Ce que ça change pour construire un SaaS en 2026
Le bottleneck se déplace
Si vous construisez un SaaS aujourd'hui, votre bottleneck n'est plus l'écriture de code. C'est la qualité de la spécification, la vitesse de review, et la capacité à valider ce qui a été produit.
Les équipes qui comprennent cela investissent dans :
- Des specs plus précises et plus actionnables (puisque l'IA les exécute)
- Des pipelines de review automatisés (tests, linting, vérifications contractuelles)
- Une culture de la validation rapide plutôt que de la production de masse
Le piège du volume de code
Le risque pour une jeune startup SaaS est de tomber dans le piège : "plus de code = plus de features = plus de valeur". Les données de Linear montrent que ce n'est pas vrai. Plus de PRs ne signifie pas plus de livraison.
Les équipes les plus efficaces sont celles qui :
- Écrivent moins de code, mais mieux spécifié — l'IA exécute, l'humain spécifie
- Automatisent la review — tests, linting, vérifications de sécurité en pipeline
- Mesurent l'impact, pas le volume — features livrées, pas PRs créées
Architecture agent-native : le pattern gagnant
Pour les SaaS qui veulent intégrer l'IA durablement, le pattern qui émerge est celui de l'architecture agent-native. Au lieu de greffer un chatbot sur une app UI-first, on définit l'application comme un ensemble d'actions métier unifiées.
// Exemple d'architecture action unifiée (UI + agent)
export const createProject = defineAction({
input: z.object({
name: z.string(),
description: z.string().optional(),
teamId: z.string(),
}),
execute: async ({ name, description, teamId }) => {
const project = await db.project.create({ name, description, teamId });
await notifyTeam(teamId, `New project: ${name}`);
return project;
},
});
Cette action sert à la fois de bouton dans l'interface et de tool pour l'agent. Une seule source de vérité, zéro dérive. C'est exactement le genre d'architecture qui permet de capter les gains de productivité de l'IA sans subir la duplication.
Les leçons pour les fondateurs de SaaS
Si on résume ce que les données de Linear enseignent aux fondateurs tech :
- L'IA double la production de code, pas la livraison de valeur — ne vous laissez pas berner par le volume
- Le vrai gain est dans la qualité de la spécification — investissez dans la clarté des specs, pas dans la vitesse d'écriture
- L'architecture compte plus que jamais — une base agent-native vous évite la duplication coûteuse
- Les métriques importent — mesurez l'impact, pas l'output. PRs count ≠ productivité
Conclusion
Les données de Linear confirment ce que beaucoup de développeurs SaaS ressentent : l'IA change profondément la façon de construire, mais pas encore la façon de décider quoi construire. Le bottleneck s'est déplacé de l'écriture vers la spécification et la review.
Pour les équipes qui construisent un SaaS aujourd'hui, le message est clair : investissez dans la qualité de vos specs, automatisez votre pipeline de validation, et architectez votre produit pour que l'IA soit native — pas une greffe.
Le futur n'appartient pas aux équipes qui écrivent le plus de code, mais à celles qui spécifient le mieux ce qu'il faut construire.
