Pourquoi réinventer ce qui existe déjà, ou ce qui deviendra natif demain

Je vois beaucoup d’équipes investir du temps et de l’argent à copier ou reproduire des skills génériques pour leurs agents: lire un dépôt, ouvrir une pull request, interroger une base, résumer un ticket, naviguer dans une documentation. Ces capacités existent déjà, sous forme de plugins, de serveurs MCP ou d’intégrations maintenues par d’autres. Est-ce vraiment le bon investissement?

Le cas du copier-coller est le plus révélateur. On prend un skill qui existe, on le recopie chez soi pour l’adapter à la marge, et on en devient propriétaire sans l’avoir choisi: chaque correction de l’original doit être reportée à la main, chaque évolution du modèle ou de l’outil sous-jacent doit être suivie, et personne dans l’équipe n’a la connaissance qui a produit la première version.

On a acheté une dette de maintenance au prix d’une soirée de gain

Il y a une seconde raison de s’abstenir. Une part de ces capacités finira probablement intégrée aux modèles eux-mêmes. Ce qui demande aujourd’hui un skill dédié, un prompt soigné et trois outils sera demain une capacité native, appelée sans configuration. Le code écrit pour combler cet écart n’a pas seulement un coût: il a une date de péremption, et elle est proche.

Ce qui reste, et qui mérite l’investissement, c’est ce qui n’existe nulle part ailleurs: la connaissance du domaine, les règles de l’entreprise, les invariants du système, les conventions que l’équipe s’est données. Un skill qui encode cela ne sera jamais fourni par un plugin ni absorbé par un modèle, parce que personne d’autre ne le connaît.

La question à poser avant d’écrire un skill n’est donc pas «savons-nous le faire?», mais «sommes-nous les seuls à pouvoir le faire?».

Si la réponse est non, on l’installe. Si elle est oui, on le construit, et on le garde petit