Chaque version tourne d’abord sur nos propres agents

Il existe une façon d’héberger qui traite une mise à jour comme le problème de quelqu’un d’autre. Une version sort, elle est déployée, et la boîte de support devient la suite de tests. C’est efficace jusqu’au jour où ça ne l’est plus.

Nous faisons la version ennuyeuse à la place. Chaque version d’OpenClaw et de Hermes tourne sur nos propres agents avant d’être déployée sur ceux des autres.

Ce que cela attrape vraiment

Rarement des erreurs de logique : c’est le rôle des tests. Cela attrape la catégorie qui n’apparaît que dans un système en fonctionnement, avec un vrai historique derrière lui :

• Une configuration qui ne veut plus dire ce qu’elle voulait dire, si bien que l’agent revient subtilement différent.
• Des redémarrages plus longs que prévu sous une charge réelle plutôt que sur une installation neuve.
• Des reconnexions de canaux qui fonctionnent sur une configuration propre et calent sur une configuration en service depuis des mois.

Ce que cela n’attrape pas

Notre usage n’est pas le vôtre. Nous n’avons pas toutes les combinaisons de canaux, toutes les compétences ni toutes les intégrations en jeu : c’est donc un filtre, pas une garantie. C’est précisément pour cela que le tableau de bord garde la mise à jour, l’annulation, la pause, le redémarrage et la réinstallation comme des actions que vous contrôlez plutôt que des demandes à formuler.

Tester sur nous-mêmes vous garantit une liste de surprises plus courte, pas une liste vide.

Cela change aussi les incitations d’une façon qui nous convient. Quand une version est bancale, nous le découvrons en premier, à notre propre bureau, avant que quiconque ait à écrire au support.