J’ai passé environ un mois à essayer de remplacer les modèles propriétaires de notre pipeline de développement par des modèles open-weight.
Un mois que j’aurais pu consacrer au produit lui-même. J’ai fait ce pari parce que chaque rôle spécialisé d’OwlMeans appelle un modèle de langage. Un changement à ce niveau touche tout le flux de développement.
À l’époque, notre preset combinait des modèles d’Anthropic et d’OpenAI. J’ai essayé GLM, Kimi, DeepSeek et Qwen chez des fournisseurs qui les hébergent. Je voulais savoir si un autre preset pouvait faire le même travail de façon fiable.
Cette expérience de juin n’est pas un benchmark. Elle n’établit aucun avantage de coût pour OwlMeans.
Notre pipeline découpe un produit en petits morceaux. Un rôle travaille sur une user story, une décision de conception ou une modification de code bien délimitée. Il reçoit le contexte de cette tâche, pas une demande d’inventer toute l’application.
Je pensais que cette structure pourrait simplifier le changement de modèle. Si la tâche était assez circonscrite, le modèle aurait peut-être moins d’occasions de mal la comprendre.
C’était une hypothèse d’ingénierie que je pouvais tester dans mon propre système. C’était aussi un détour tentant pour un fondateur solo. Améliorer la machinerie semblait utile à tous les projets à venir, et il devenait facile de justifier une journée de réglages de plus.
Il me fallait regarder l’exécution dans son ensemble, et pas seulement l’app qu’elle produisait.
Des réponses vides
Le premier problème est venu du raisonnement.
Certains modèles dépensaient le budget de sortie disponible en raisonnement interne et ne renvoyaient aucun contenu exploitable. Le rôle de codeur terminait sa requête, mais l’étape suivante n’avait rien à appliquer.
J’ai essayé de désactiver le raisonnement avec un paramètre que le fournisseur ne respectait pas toujours. Puis j’ai posé des limites explicites autour des rôles concernés, et je les ai ajustées modèle par modèle.
Ça m’a demandé plus d’attention que ne le laissait penser le changement de preset. Un rôle de planification et un codeur n’avaient pas besoin du même traitement. Un réglage qui marchait pour un modèle n’était pas une règle que je pouvais recopier sans risque sur les autres.
Le problème suivant touchait au format des réponses. Nos étapes se transmettent des résultats structurés. Une réponse qui me paraît sensée peut quand même ne pas respecter le schéma qu’attend l’étape suivante.
J’ai ajouté un chemin par appel d’outil pour les cas où un modèle n’arrivait pas à renvoyer de façon fiable la structure attendue. J’ai aussi changé la manière dont le code circulait dans le pipeline : l’agent travaillait sur les extraits pertinents et sur des patchs, au lieu de manipuler sans cesse des fichiers entiers.
Ces changements sont venus s’ajouter au système que je devais maintenir. L’expérience dépassait déjà le simple choix d’un modèle dans une liste.
Le fournisseur au milieu
Le nom d’un modèle ne suffisait pas à identifier tout l’environnement d’exécution.
L’hébergeur influait sur les fonctionnalités disponibles et sur le comportement des requêtes. J’ai testé des fournisseurs, puis j’ai fini par utiliser le routage et le basculement d’OpenRouter dans le preset expérimental.
La documentation d’OpenRouter sur le routage entre fournisseurs explique les réglages disponibles pour choisir et filtrer les hébergeurs. Mon pipeline dépendait d’une forme de réponse précise, donc ces réglages comptaient. Il m’a quand même fallu tester la route complète que j’utilisais.
J’ai enfin pu passer d’un preset à l’autre et faire tourner le même projet avec chacun. À ce stade, le changement de preset traînait derrière lui les limites de raisonnement, la gestion des réponses, l’extraction du code et les choix de fournisseurs.
L’app à l’arrivée
Lors de ces exécutions, les applications obtenues se ressemblaient dans les grandes lignes. J’ai remarqué des différences de CSS et, de temps en temps, des ajouts à l’interface que je n’avais pas demandés.
J’ai aussi vu des modèles compétents enjoliver une petite tâche alors que je voulais une implémentation littérale. C’était une observation sur mes tâches et ma configuration. Ce serait une mauvaise base pour classer les modèles en général.
Moi qui faisais tourner le système, j’ai dû composer avec des différences moins visibles. Les résultats structurés ratés demandaient une nouvelle tentative, et je devais m’occuper des patchs qui ne s’appliquaient pas. Même une étape banale pouvait s’arrêter à cause d’une incompatibilité avec le fournisseur.
Une capture d’écran finale cache ce travail.
Remplacer les modèles voulait dire prendre en charge plus de travail dans le pipeline.
J’avais une comparaison informelle, tirée de mes propres mesures. Je ne m’y fiais pas assez pour en faire une affirmation générale sur les performances.
Les modèles n’étaient pas réglés de la même façon. Le comportement des fournisseurs faisait partie du résultat. Avec les relances et les étapes de réparation, le chemin suivi pendant une exécution comptait autant que l’artefact final.
Une vraie comparaison demanderait une tâche définie, les mêmes vérifications d’acceptation, des mesures cohérentes et des échecs consignés. Mes exécutions m’avaient donné des notes d’ingénieur.
Cette révision laisse donc de côté l’ancien titre chiffré. L’adresse publique ne change pas, pour que les liens existants continuent de fonctionner.
Il me restait à décider où passer mon temps. Je pouvais continuer à régler le preset expérimental, ou revenir au reste du produit. D’autres mesures ne serviraient que si elles éclairaient une décision que j’avais vraiment à prendre.
Un mois de réglages
J’ai gardé un chemin qui fonctionne pour essayer différents modèles. J’ai aussi mis au jour plusieurs hypothèses cachées dans le pipeline : comment un rôle raisonne, comment il renvoie un résultat, quelle quantité de code source il reçoit et ce qui se passe quand son fournisseur tombe en panne.
Ce sont des connaissances utiles pour le moteur que je construis. Elles ne prouvent pas qu’un autre fondateur devrait refaire la même expérience.
Si c’était à refaire, je fixerais plus tôt les conditions d’arrêt. Je déciderais quels types d’échec il me faudrait comprendre avant de passer une semaine de plus à changer des réglages.
Ce mois m’a permis de mieux comprendre mon propre système. C’est aussi un mois en moins pour le reste d’OwlMeans. Les deux entrent dans le bilan.
Révisé le 15 octobre 2026. Cette version conserve l’expérience de juin. Le comportement des modèles et des fournisseurs a continué d’évoluer ; les observations ci-dessus décrivent ces exécutions-là.