Il y a des années, j'ai configuré le scheduler de notre appli Laravel pour lancer chaque tâche de nettoyage en file une fois par minute, parce que le CPU ne coûtait rien et que je n'avais pas envie de réfléchir à la fréquence dont chacune avait vraiment besoin. Il a fallu huit mois et une facture d'hébergement franchement déroutante pour que quelqu'un demande pourquoi une tâche qui purge les jetons de réinitialisation de mot de passe expirés se réveillait 1440 fois par jour. Je repense sans arrêt à cette ligne de cron en lisant ce qui se dit sur Beam, le nouveau modèle open-weight de Reflection, parce que la fonctionnalité qui a retenu mon attention n'a rien à voir avec sa capacité à réfléchir fort. Ce qui m'a accroché, c'est qu'on peut lui demander de réfléchir moins.

Les chiffres phares sont impressionnants, et ils méritent leur moment de gloire. Beam compte 501 milliards de paramètres dans une architecture mixture-of-experts creuse, dont 23 milliards actifs par token, 52 couches et une fenêtre de contexte étendue à 1 million de tokens pendant le midtraining. Reflection annonce 80.9% sur SWE-Bench Verified, 80.1% sur Terminal-Bench v2.1 et 78.7% sur MCP Atlas, et affirme que les poids, les rapports techniques et les artefacts pour développeurs seront publiés sous Apache 2.0. Pour un modèle ouvert, ce sont des résultats sérieux. Mais ils décrivent un plafond, et la plupart d'entre nous ne passent pas leurs après-midi près du plafond.

Sois honnête sur ce que tu confies vraiment à un agent de code un mardi. Renommer une classe de service et mettre à jour quarante appels. Ajouter une colonne nullable et écrire la migration. Faire passer un vieux contrôleur du niveau 5 au niveau 6 de PHPStan sans changer son comportement. Transformer un partial Blade en composant. Rien de tout ça n'exige qu'un modèle délibère pendant douze mille tokens avant de toucher un fichier, et pourtant chaque agent que j'ai fait tourner a tendance à facturer comme s'il soutenait une thèse. Beam a été entraîné avec une pénalité de longueur contrôlable, et Reflection expose un paramètre d'effort de raisonnement que tu peux baisser pour le travail de routine et monter pour les cas tordus. L'entreprise affirme qu'il égale GLM-5.2 sur les benchmarks de raisonnement avancé tout en consommant trois à quatre fois moins de calcul d'inférence. Si ça tient en bas du cadran, ça change ce que coûte la génération d'une pull request.

L'objection la plus sérieuse, je la partage. Un cadran n'est utile que si sa position la plus basse reste compétente, et tous les scores de l'annonce sont des scores vitrine. Je n'ai vu personne publier ce que donne Beam sur SWE-Bench avec l'effort réglé au minimum, et tant que personne ne le fait, « concis pour les tâches de routine » reste une promesse sans chiffre. Il y a aussi une deuxième objection : faire tourner 501 milliards de paramètres soi-même n'a rien d'un projet du week-end, donc pour la plupart des boîtes PHP, « poids ouverts » veut surtout dire « un hébergeur que tu choisis ». Ton laptop ne fait pas partie de la liste. Les deux remarques sont justes, et je voudrais qu'elles soient tranchées avant de recâbler la CI de qui que ce soit autour de ce modèle.

Je penche quand même du côté du bouton, et la raison tient à la façon dont Reflection a construit le modèle. Ils rapportent un pretraining sur 6144 GPU NVIDIA GB300 NVL72 avec un goodput de 92.3% et seulement neuf retours en arrière semi-automatiques, puis une phase de RL sur 10.5K GB300 qui a déclenché plus de 1.3 milliard de requêtes de création de sandbox sur 170K environnements simultanés. C'est une équipe qui traque visiblement les cycles gaspillés chez elle. Livrer un modèle dont le comportement par défaut peut lui aussi arrêter de gaspiller des cycles relève du même réflexe, et c'est le réflexe que notre côté du métier a toujours dû avoir, parce que c'est nous qui faisons tourner dix mille petites requêtes sur des machines modestes, toutes les heures, pendant des années.

Concrètement, ça a une conséquence pour quiconque construit des outils autour de projets PHP. Si l'effort est un paramètre, il a sa place dans ta config à côté du nom du modèle, et il doit varier selon le type de tâche. Un refactoring mécanique façon Rector et la traque d'une race condition dans un queue worker ne devraient pas partager le même réglage, pas plus que ta tâche de nettoyage et ton rapport nocturne ne devraient partager le même planning cron. Reflection affirme aussi que Beam a appris à utiliser des outils pour lesquels il n'a pas été explicitement entraîné, comme chercher dans la documentation ou appeler des API d'OCR. C'est impressionnant, mais ça veut aussi dire qu'un agent configuré trop généreusement partira volontiers se balader sur le web alors que tu lui demandais juste de corriger un import. Un effort bas peut servir de laisse autant que de remise.

La licence Apache 2.0 compte ici plus qu'on pourrait le croire. Avec une licence permissive, un hébergeur peut proposer Beam à un prix qui reflète le niveau d'effort demandé, et une agence qui facture ses clients au projet pourra un jour raisonner sur le coût de l'IA comme elle raisonne sur le coût des serveurs : en requêtes et en minutes, avec une ligne dans un tableur. C'est une relation plus saine que de payer un supplément forfaitaire pour une réflexion maximale sur chaque diff trivial en espérant que la facture reste polie.

Alors voilà ce que j'aimerais sincèrement savoir. Si tu fais déjà tourner des agents de code sur une vraie base PHP, quelle part de ce travail demande honnêtement un raisonnement poussé, et ferais-tu confiance à un modèle réglé sur son effort minimum pour livrer une migration ou un refactoring mécanique sans qu'un humain relise chaque ligne ? Où placerais-tu la limite ?