Le conseil qui semble prudent, c'est d'attendre. Laisser un nouveau modèle faire ses preuves, laisser les autres en découvrir les aspérités, l'adopter une fois qu'il est devenu banal. Nous faisons l'inverse, délibérément. Quand un modèle nettement meilleur sort, nous le testons cette semaine-là. Non par goût du risque, mais parce que le coût d'avoir un an de retard sur les capacités est plus élevé et plus silencieux que celui d'une mise à niveau précoce.

L'astuce, c'est que adoption précoce et imprudence ne sont pas la même chose. On peut bouger en premier tout en restant prudent, à condition que le système soit conçu pour vous le permettre.

Le coût de l'attente est invisible, et c'est pour cela qu'il est dangereux

Quand vous adoptez un nouveau modèle tôt et qu'il dérape, le coût est bruyant et immédiat. Vous le voyez, vous le corrigez. Quand vous attendez, le coût est silencieux. Votre produit résout des problèmes avec les capacités de l'an dernier pendant que celui d'un concurrent les résout avec celles de cette année. Personne n'ouvre un ticket disant « nous sommes discrètement moins bons que nous pourrions l'être ». La facture arrive quand même, simplement elle ne s'annonce jamais.

Une génération de modèle peut faire la différence entre une fonctionnalité qui marche et une qui ne sort jamais. Renoncer à combler cet écart pour se sentir en sécurité est une décision qui a un prix, même quand ce prix est difficile à voir.

Attendre paraît sûr parce que le coût de l'attente ne vous envoie jamais de facture.

Précoce ne veut pas dire non éprouvé en production

Soyons clairs sur ce que nous faisons réellement. Nous testons les nouveaux modèles la semaine de leur sortie. Nous ne les exposons pas aux utilisateurs en production cette même semaine. Ce sont deux choses différentes, et les confondre, c'est précisément là que les équipes se brûlent.

L'adoption précoce est une évaluation, menée vite. Nous intégrons d'abord le nouveau modèle dans notre propre pipeline, nous le mesurons sur le travail que nous comprenons déjà, et nous découvrons où il est meilleur et où il est moins bon. La capacité ne progresse jamais uniformément. Un nouveau modèle peut raisonner plus finement et respecter moins bien un format strict. On ne l'apprend qu'en l'exécutant, pas en lisant l'annonce.

Le garde-fou, c'est de pouvoir changer

La raison pour laquelle nous pouvons bouger vite, c'est que rien de ce que nous construisons n'est soudé à un seul modèle. Nous passons par une interface unique commune aux différents fournisseurs, si bien qu'un modèle est un réglage, pas une fondation. En remplacer un, ou se rabattre sur un autre les jours où il flanche, est un changement de configuration plutôt qu'une réécriture.

C'est cette seule décision qui transforme l'adoption précoce d'un pari en une routine. Si le nouveau modèle l'emporte sur nos évaluations, nous le promouvons. S'il régresse quelque part où ça compte, nous gardons l'ancien et nous attendons le suivant. Nous ne sommes jamais piégés, donc essayer ne coûte presque rien. C'est le verrouillage qui constitue le risque. Supprimez-le et la frontière cesse de faire peur.

Mesurer plutôt que deviner

Ce qui rend tout cela rigoureux plutôt qu'une affaire de ressenti, c'est la comparaison. Nous ne décrétons pas qu'un modèle est meilleur parce qu'il a paru plus affûté dans une conversation. Nous l'essayons sur des cas réels tirés de travaux passés et nous le confrontons directement au modèle que nous utilisons déjà, pour que la décision repose sur des résultats plutôt que sur une première impression.

C'est aussi ainsi que nous évitons l'échec inverse, courir après la nouveauté pour elle-même. Un nouveau modèle qui ne bat pas l'actuel sur les tâches qui nous importent ne part pas en production, aussi enthousiasmant qu'ait été son lancement. La barre n'est pas « nouveau ». La barre est « meilleur », mesuré sur du travail qui compte.

La frontière, ceinture bouclée

Vivre à la frontière est un avantage concurrentiel quand, et seulement quand, vous avez d'abord construit la ceinture de sécurité. Une interface agnostique vis-à-vis du fournisseur, pour que changer coûte peu. L'habitude de tester sur des cas réels, pour que les mises à niveau soient des décisions et non des paris. Une ligne claire entre tester un modèle et lui confier des utilisateurs. Une fois cela en place, l'adoption précoce n'est pas un risque que vous prenez. C'est une habitude qui compose ses effets, pendant que tous ceux qui attendent que ce soit sûr prennent lentement une génération de retard.