Gemini 3.1 Pro face à Gemini 3.7 Flash pour la maintenance du code : comment mesurer si le surcoût en vaut la peine

La décision : payer pour une tâche résolue, pas pour une impression

Choisir entre Gemini 3.1 Pro et Gemini 3.7 Flash pour maintenir du code ne revient pas à demander lequel est « meilleur ». Pour une équipe, la question pratique est de savoir quel modèle mène à bien une tâche donnée avec un correctif correct, combien coûte l’obtention de ce résultat et combien de temps elle demande. Un modèle qui répond vite, mais introduit une régression ou nécessite plusieurs cycles de correction, peut se révéler moins efficace qu’un modèle dont chaque appel coûte davantage.

Une comparaison utile doit porter sur le travail réellement terminé. Il faut donc évaluer si la modification répond au problème signalé, passe les tests pertinents et évite de toucher à des éléments sans rapport avec la demande. Il faut aussi comptabiliser les tentatives infructueuses, les outils utilisés, les nouvelles tentatives, l’intervention humaine et les exécutions qui ne débouchent pas sur un correctif acceptable. Le coût par appel, à lui seul, ne décrit pas le coût de la maintenance d’un dépôt.

Nous ne disposons pas ici des résultats d’un essai mené sur les mêmes dépôts et avec un même harnais. Il serait donc imprudent d’affirmer que Flash suffit pour les tâches courantes, que Pro justifie son coût pour les tâches complexes ou que l’un des deux l’emporte. Ce qui suit est un protocole permettant d’obtenir une réponse, ainsi qu’un guide pour interpréter les résultats sans présenter des hypothèses comme des faits.

Quels modèles comparer et que vérifier avant de commencer

La première étape consiste à fixer l’identité exacte de chaque système. La fiche officielle consultée identifie Gemini 3.1 Pro sous l’ID `gemini-3.1-pro-preview` et indique qu’il s’agit d’une version Preview. Le guide sur le raisonnement consulté inclut `gemini-3.7-flash` et `gemini-3.1-pro-preview` parmi les modèles pour lesquels il fournit des informations de configuration. Ces noms ne doivent pas être remplacés par des appellations abrégées dans les journaux de l’essai : l’identifiant envoyé à l’API fait partie de la configuration expérimentale.

La disponibilité et le statut peuvent évoluer. Avant de lancer les exécutions, puis à nouveau à la clôture de l’essai, il faut vérifier les identifiants acceptés, le canal utilisé et si l’un des modèles est devenu indisponible ou a changé de statut. Si un modèle change pendant l’essai, l’article doit préciser quelles exécutions correspondent à chaque version ou séparer les périodes. Il ne faut pas les traiter silencieusement comme un échantillon homogène.

Il faut également consigner le fournisseur et le canal d’accès, la date, les paramètres de génération, la limite de contexte, les règles d’arrêt et toute configuration de raisonnement. La documentation officielle décrit des options et des valeurs par défaut, mais cela ne prouve pas que deux valeurs portant le même nom correspondent au même effort de calcul, au même budget interne ou au même comportement. Une comparaison fondée sur des niveaux « équivalents » n’est défendable que si l’équivalence est définie de manière opérationnelle et si les paramètres réellement utilisés sont publiés.

Les tarifs ne doivent pas non plus être repris d’un ancien tableau ni déduits du nom du modèle. Il faut vérifier les composantes de facturation applicables à la date de l’essai et préciser ce qui est inclus : entrées, sorties, appels aux outils ou autres frais pertinents. Si l’accès passe par une couche intermédiaire ou applique un tarif différent de celui de l’API directe, ce canal doit être mesuré et décrit : les résultats ne se transposent pas automatiquement à un autre mode d’accès.

Conception : dépôts, problèmes et critères d’acceptation

Le jeu d’essai doit être figé avant l’exécution des modèles. Chaque tâche doit être associée à un dépôt et à un commit de base identifiables, à une description du problème, à un environnement reproductible et à des critères d’acceptation définis à l’avance. Modifier les tâches ou les règles après avoir découvert quel modèle a produit chaque correctif augmente le risque d’ajuster l’évaluation aux résultats.

Il est préférable de sélectionner des problèmes issus de dépôts différents et de les répartir par type et difficulté : diagnostic d’un défaut, correction circonscrite, modification touchant plusieurs fichiers et tâche pour laquelle les tests existants ne couvrent pas entièrement le comportement attendu. La répartition doit être publiée. Une collection dominée par de petites modifications pourrait favoriser un profil de travail ; une collection composée surtout de problèmes étendus pourrait en favoriser un autre. La diversité réduit ce risque sans le faire disparaître.

Les problèmes doivent être authentiques et pertinents pour la maintenance, mais leur sélection demande de la prudence. L’article de recherche sur SWE-bench décrit un précédent fondé sur des problèmes issus de véritables issues GitHub. La documentation de ses jeux de données et de son harnais peut guider la conception d’une évaluation, mais utiliser les tâches d’un benchmark ne garantit pas qu’un essai donné mesure correctement le travail d’une équipe. Par ailleurs, OpenAI a publié une mise en garde concernant les limites de SWE-bench Verified ; cette mise en garde doit être attribuée à OpenAI et non présentée comme un audit indépendant des modèles comparés ici.

Pour réduire le risque de contamination, il faut vérifier si la solution ou un correctif équivalent figure déjà dans le contexte fourni, dans les fichiers de la tâche ou dans les ressources accessibles au système. Il est également important de décrire les informations reçues par chaque modèle : issue, historique, consignes, documentation et tests. Dire simplement que les deux modèles ont reçu « le même prompt » ne suffit pas si l’un a eu accès à des données supplémentaires ou à des outils différents.

Les tâches doivent être exécutées sur des copies propres du même commit. Le harnais, les dépendances et les commandes de test doivent rester identiques. Un environnement reproductible aide à distinguer l’effet du modèle de celui d’une machine, d’une version de dépendance ou d’une modification manuelle du dépôt. Si une tâche échoue en raison de l’infrastructure et non du correctif, elle doit être étiquetée selon une règle définie avant l’examen des résultats.

Définir une « tâche acceptée » avant d’examiner les correctifs

Réussir un test ne signifie pas automatiquement que la solution est acceptable. Les tests existants peuvent ne pas couvrir l’exigence centrale, et un correctif peut les faire passer au prix d’une modification trop large ou d’un changement qui masque le problème. L’acceptation doit associer des tests automatisés pertinents à une revue humaine structurée.

La grille d’évaluation doit au minimum déterminer si le correctif résout le problème, préserve les comportements sans rapport avec celui-ci, introduit des régressions connues, modifie uniquement ce qui est nécessaire et reste maintenable. Elle doit préciser la conduite à tenir lorsque le résultat semble correct, mais que les tests sont insuffisants. Dans ces cas, il est possible d’ajouter des vérifications indépendantes ou de classer la tâche comme incertaine, plutôt que d’imposer un succès ou un échec dépourvu de preuves.

Les personnes chargées de la revue devraient recevoir des correctifs anonymisés et appliquer la même grille sans connaître le modèle d’origine. Il est utile de consigner les désaccords et de prévoir une procédure de résolution, par exemple une seconde revue. L’évaluation humaine n’est pas infaillible non plus : la définition de l’acceptation, les catégories de rejet et la proportion de décisions contestées doivent donc être publiées.

Deux lectures distinctes : budget commun et délai commun

Une comparaison à budget identique et une comparaison à temps identique répondent à des questions différentes. Elles ne doivent pas être fusionnées en un chiffre unique. Dans le premier cas, un plafond de dépense par tâche est attribué à chaque modèle, en incluant les composantes de facturation définies pour l’essai. On observe combien de tâches le modèle termine avec un correctif acceptable avant d’atteindre cette limite. Une tentative infructueuse consomme une partie du budget et doit rester dans les résultats.

Dans le second cas, les deux modèles disposent du même délai maximal, mesuré entre le début de la tâche et la remise du résultat. Le chronomètre doit inclure les attentes, les appels aux outils, les nouvelles tentatives et toute autre latence ressentie par l’utilisateur. Si le temps de revue humaine est mesuré séparément, il faut le préciser ; s’il est inclus, la même procédure doit s’appliquer aux deux modèles. Sinon, comparer le seul temps de réponse du modèle au temps total d’un flux de travail revient à mélanger des mesures différentes.

Pour que les conditions soient équitables, il faut les définir avant l’exécution : dépense maximale, délai, nombre de nouvelles tentatives, limite d’étapes, permissions et règle d’arrêt. Si le modèle atteint la limite sans fournir de correctif acceptable, la tâche est non résolue dans cette condition ; ce n’est pas une exécution à retirer de l’analyse. Cette méthode répond à une question d’achat précise : que peut-on obtenir avec un montant maximal ou dans un créneau de temps donné ?

Que mesurer par tâche et par catégorie

La mesure centrale devrait être le taux d’acceptation : la proportion d’exécutions qui produisent un correctif accepté selon la grille. Pour être interprétable, ce taux doit être accompagné du nombre total de tâches et de tentatives, et non présenté seul sous forme de pourcentage. Un taux élevé obtenu sur peu d’exécutions comporte une incertitude différente du même taux observé sur un ensemble plus vaste.

Il faut rendre compte des régressions, des tests pertinents réussis, des modifications superflues, des nouvelles tentatives, des erreurs de service, de l’intervention humaine et des tâches qui se terminent sans correctif. La dépense peut être exprimée par tentative et par correctif accepté, à condition d’indiquer la formule et les composantes de facturation. Si un modèle ne résout pas une tâche, son coût ne disparaît pas du calcul : exclure les échecs donnerait une image artificiellement favorable du coût par réussite.

La latence doit être ventilée, au minimum, entre le temps du modèle, l’attente ou la mise en file d’attente lorsqu’elle peut être mesurée, les opérations avec les outils et le temps total jusqu’à la livraison. Pour les équipes, la durée de revue et de correction manuelle peut également compter. Deux modèles dont les temps de génération sont similaires peuvent imposer des charges différentes si l’un nécessite davantage de vérifications ou de réparations.

Les résultats doivent être ventilés par type et par difficulté de tâche, en plus d’un résumé général. Le chiffre agrégé peut masquer le fait qu’un modèle réussit mieux les petites modifications tandis que l’autre évite davantage d’échecs sur des changements touchant plusieurs fichiers. Il ne faut pas qualifier de « meilleur » un résultat qui domine une moyenne si les tâches du lectorat correspondent à un profil différent.

Répétitions, défaillances du service et incertitude

La sortie d’un modèle peut varier d’une exécution à l’autre, même lorsque la tâche et l’environnement ne changent pas. Une seule exécution par problème ne suffit donc pas à décrire sa stabilité. Le nombre de répétitions doit être fixé avant le début, justifié au regard de la portée de l’essai et identique pour chaque modèle et chaque tâche. Lorsque les conditions de service empêchent de terminer une exécution, il faut distinguer une erreur d’infrastructure d’un échec du modèle, sans effacer la donnée.

Il faut montrer la variation et l’incertitude, pas seulement une moyenne. Il est possible de publier les décomptes, des intervalles adaptés et les résultats par tâche ; la méthode statistique à retenir dépend du plan d’expérience et doit être décrite. Si l’ensemble est réduit, la conclusion doit rester limitée : une différence observée dans ces cas ne prouve pas qu’elle se retrouvera avec d’autres langages, dépôts, équipes ou niveaux de difficulté.

La sensibilité au harnais compte également. Modifier le prompt, la limite d’utilisation des outils, le budget de contexte ou les règles d’arrêt peut changer le résultat. Un essai contrôlé mesure l’effet d’une configuration donnée ; il ne mesure pas une capacité universelle indépendamment des conditions d’utilisation. Si d’autres essais sont menés avec des configurations différentes, ils doivent être présentés séparément et non mélangés aux résultats principaux.

Matrice de décision pour les équipes d’ingénierie

Sans résultats d’essai, la matrice ne peut attribuer d’avantage empirique ni à Gemini 3.1 Pro ni à Gemini 3.7 Flash. Elle peut néanmoins aider à traduire les données recueillies en une décision adaptée au travail de l’équipe. La comparaison doit tenir compte du seuil minimal de qualité : si un modèle n’atteint pas le taux d’acceptation ou le niveau de sûreté requis, un coût faible ne suffit pas à compenser cet écart.

Pour des tâches courantes et bien délimitées, l’équipe peut d’abord vérifier si Flash atteint ce seuil dans le cadre du budget et du délai retenus. Il s’agit d’une hypothèse à tester, et non d’une propriété démontrée ici. Pour les tâches difficiles, les modifications étendues ou les changements à conséquences importantes, il faut déterminer si Pro améliore suffisamment le taux d’acceptation ou réduit l’intervention humaine pour justifier la dépense supplémentaire, sans supposer que le nom Pro garantit ce résultat.

Dans les deux cas, le flux de travail doit conserver une revue humaine lorsque le risque du changement le justifie. Si les deux modèles produisent fréquemment des correctifs à reprendre, ou si les tests disponibles ne permettent pas de vérifier le comportement, il peut être raisonnable de conclure qu’aucun ne satisfait aux critères d’automatisation pour cette catégorie de travail. Une approche hybride est également possible, à condition de mesurer l’orientation des tâches entre modèles et de ne pas tenir pour acquis qu’un routage selon la difficulté améliore les résultats.

Matériel de reproduction et limites des conclusions

Une comparaison destinée à éclairer une décision d’ingénierie doit publier le protocole, les tâches retenues, les commits de base, la configuration de chaque modèle, les limites et la grille d’acceptation. Lorsque les permissions et les licences le permettent, il est également utile de fournir les correctifs, les journaux anonymisés, les résultats des tests et les motifs de rejet. Les exclusions et les tentatives infructueuses font partie des éléments probants ; ce ne sont pas des détails secondaires.

Le harnais peut s’inspirer de pratiques d’évaluation reproductible, comme l’exécution des correctifs dans des environnements isolés et le contrôle de l’application des modifications. La documentation du harnais SWE-bench décrit une approche utilisant des environnements Docker pour exécuter les tâches et les évaluer. Il s’agit d’une référence méthodologique : cela ne signifie pas que l’utilisation de ce harnais garantit, à elle seule, que l’essai représente le flux de travail d’une entreprise.

Les résultats n’étayeront que des conclusions sur les modèles, les versions, les tâches, la configuration et la date qui auront été documentés. Ils ne permettront pas de déduire automatiquement le comportement d’autres produits Google, d’autres versions ou d’autres fournisseurs. Ils ne remplacent pas non plus une évaluation sur des dépôts privés, avec les règles de sécurité et de revue propres à l’équipe. La question « quand le surcoût en vaut-il la peine par tâche résolue ? » ne peut recevoir une réponse qu’après avoir défini ce qui constitue une tâche résolue et mesuré le coût complet dans le contexte pertinent.

Pour l’instant, la conclusion éditoriale rigoureuse n’est pas de désigner un gagnant, mais de poser une condition de décision : comparer les deux modèles sur des tâches figées, avec une acceptation évaluée à l’aveugle, des limites communes de dépense et de temps, et une publication de l’incertitude. Si les données montrent des différences cohérentes et utiles pour le profil de l’équipe, il sera possible de recommander une option pour cet usage. Dans le cas contraire, il sera plus honnête de dire que les éléments disponibles ne permettent pas de les départager.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.