Le critère que les comparatifs ne traitent pas
Les comparatifs d'assistants de code évaluent la qualité de la complétion ; les organisations décident sur le trajet du code et sur ce que le fournisseur en fait. Les deux questions n'ont presque aucun rapport.
La qualité de complétion se mesure sur des exercices publics, elle progresse vite, et l'écart entre les outils de tête se réduit à chaque génération. C'est donc le critère le moins discriminant.
Le trajet du code, lui, varie énormément d'une offre à l'autre : ce qui est envoyé, ce qui est conservé, pour combien de temps, et si cela sert à entraîner. Ces différences sont contractuelles, stables, et elles décident de ce que l'organisation a le droit d'utiliser.
Les quatre questions à poser au fournisseur
Qu'est-ce qui est envoyé, qu'est-ce qui est conservé, combien de temps, et à quoi cela sert. Ces quatre questions se posent avant toute démonstration.
Ce qui est envoyé : le fichier courant seulement, ou le contexte du dépôt ? Certains outils indexent l'ensemble du code pour améliorer leurs suggestions, ce qui est un transfert d'une tout autre ampleur.
Ce qui est conservé : rien, les requêtes, ou les requêtes et les réponses ? Une rétention nulle se dit et se contractualise.
Combien de temps : une durée chiffrée, pas un engagement de moyens.
À quoi cela sert : usage du service seulement, ou amélioration des modèles ? La réponse à cette dernière question suffit à écarter une offre dans un contexte contraint, et c'est la même logique que celle posée dans confidentialité : ce qu'on a le droit de mettre dans un prompt.
Ce qui compte ensuite, dans l'ordre
- La stabilité de l'offre. Un outil dont le modèle sous-jacent ou la tarification change tous les six mois coûte en réapprentissage.
- Le comportement hors ligne, pour les équipes qui travaillent sur des sites sans connexion ouverte.
- L'intégration à l'environnement existant, qui décide de l'adoption réelle bien plus que la qualité des suggestions.
- La possibilité de restreindre par dépôt, pour exclure le code le plus sensible sans priver toute l'équipe de l'outil.
Le cas du modèle local, qui règle la question par construction
Un assistant qui tourne sur le poste ne pose aucune question de transfert, et il est devenu utilisable pour la complétion courante. Ce n'est plus une position de principe.
Sur la complétion de ligne, la génération de tests unitaires et la reformulation de code, un modèle local de taille moyenne suffit. Ces trois usages représentent l'essentiel du volume quotidien.
Sur la compréhension d'une base de code entière ou le raisonnement sur une architecture, l'écart avec un grand modèle distant reste net.
La configuration mixte est donc la même que celle recommandée ailleurs : local pour le volume et le sensible, distant pour les cas difficiles sur du code qui peut sortir. Les conditions de déploiement sont détaillées dans petits modèles sur poste.
Ce qu'il faut décider en interne, avant de choisir
Quels dépôts ont le droit de sortir, et qui en décide. Sans cette décision, aucun choix d'outil n'est instruit.
La plupart des organisations ont des niveaux de sensibilité très différents entre leurs dépôts : un site vitrine, un back-office métier, un composant sous contrat client, un algorithme propriétaire. Les traiter uniformément conduit soit à interdire partout, soit à autoriser partout.
La décision utile classe les dépôts en trois catégories : ce qui peut sortir sans condition, ce qui peut sortir sous contrat de non-rétention, ce qui ne sort pas. Une demi-journée avec le responsable technique et le juridique.
Cette classification ressemble à celle des actions d'un agent par réversibilité, et pour la même raison : elle transforme une question de principe en règle applicable. Voir le périmètre avant l'autonomie.
La question qui écarte le plus d'offres en une phrase
« Le code envoyé sert-il à améliorer vos modèles, et pouvez-vous l'exclure par contrat ? » Une réponse évasive à la seconde partie suffit à écarter l'offre pour tout dépôt sensible.
Ce qu'il faut mesurer après le déploiement
Le taux d'acceptation des suggestions et le temps passé en revue, pas le nombre de lignes générées. Ce dernier chiffre est le plus mis en avant et le moins utile.
Le taux d'acceptation dit si l'outil produit du code que l'équipe garde. Un taux faible signale un mauvais réglage de contexte, pas nécessairement un mauvais outil.
Le temps de revue est le contrepoids indispensable : un assistant qui fait écrire plus vite et relire plus longtemps ne fait pas gagner de temps. C'est le point développé dans l'article suivant de cette série.
Ces deux mesures se relèvent sur un échantillon, en une semaine, et elles suffisent à décider d'une généralisation. Le principe de mesure est le même que dans mesurer l'adoption, pas la satisfaction : ce qui compte est l'usage réel à six semaines, pas l'enthousiasme initial.
Questions fréquentes
Quel critère décide vraiment en entreprise ?
Le trajet du code : ce qui est envoyé, ce qui est conservé, combien de temps, et si cela sert à entraîner. La qualité de complétion est le critère le moins discriminant entre outils de tête.
Faut-il un modèle local ?
Pour la complétion, les tests unitaires et la reformulation, il suffit et règle la question du transfert. Pour raisonner sur une base entière, l'écart avec un grand modèle distant reste net.
Que décider avant de choisir un outil ?
Quels dépôts ont le droit de sortir, en trois catégories : sans condition, sous contrat de non-rétention, jamais. Sans cette classification, aucun choix d'outil n'est instruit.
Que mesurer après déploiement ?
Le taux d'acceptation des suggestions et le temps passé en revue. Le nombre de lignes générées est le chiffre le plus mis en avant et le moins utile.