Introduction
Votre équipe utilise-t-elle des assistants de codage alimentés par l'IA ? Vous a-t-on pressé d'augmenter les taux d'utilisation ? Avez-vous remarqué que, dans de nombreux cas, les membres de l'équipe n'utilisent pas les assistants de codage alimentés par l'IA pour rédiger du code ? Au-delà du partage conventionnel de connaissances et de cas d'usage, existe-t-il d'autres méthodes efficaces pour stimuler l'utilisation ?
Depuis que mon équipe a activé GitHub Copilot il y a trois mois, ces problèmes m'ont préoccupé, cet article de blog est ma tentative de trouver des réponses.
Pourquoi augmenter le taux d'utilisation des assistants de codage alimentés par l'IA ?
Avant de discuter du « comment », nous devons d'abord clarifier le « pourquoi ». Tout repose sur une hypothèse fondamentale : les assistants de codage alimentés par l'IA peuvent améliorer l'efficacité du développement, et plus ils sont utilisés, plus l'amélioration est importante. Acceptons temporairement cette hypothèse comme valide et vérifions-la par la pratique.
Pouvons-nous donc imposer que les membres de l'équipe utilisent les assistants de codage IA dans tous leurs travaux ? Vu que l'hypothèse n'est pas prouvée, de telles actions comportent des risques importants, et si cela n'améliorait pas l'efficacité ? La clé pour gérer ce type de situation est de réduire les pertes potentielles, et la meilleure approche consiste à accorder l'autonomie aux développeurs : leur permettre de décider quand et dans quels scénarios utiliser les assistants.
Lorsque les développeurs ont cette liberté de choix, l'utilisation augmente-t-elle naturellement ? D'après l'expérience de notre équipe avec GitHub Copilot pendant trois mois, les développeurs tendent à l'utiliser fréquemment dans les scénarios suivants :
Compréhension du code. ; Analyse des solutions. ; Refactorisation de code au niveau des fonctions. ; Implémentation d'algorithmes au niveau des fonctions. ; Génération de tests unitaires.
Ils l'utilisent rarement dans ces scénarios :
Modifications de code au niveau des lignes. Modifications réalisables autrement avec les raccourcis IDE.. Corrections de bogues. Implémentations de tâches complexes (notamment celles couvrant plusieurs fichiers ou modules).
Du point de vue des suggestions de code inline, le taux d'utilisation atteint déjà presque 100 %, car ces fonctionnalités sont activées par défaut. Mais les suggestions au niveau des lignes offrent une aide limitée : elles ne réduisent pas la charge cognitive et ne peuvent donc pas améliorer significativement l'efficacité du développement.
Pour aller plus loin, la clé réside dans l'augmentation du taux d'utilisation dans les scénarios complexes. Comment atteindre cet objectif lorsque les développeurs disposent d'une autonomie ? C'est l'objet des sections suivantes.
Un modèle de taux d'utilisation pour les assistants de codage alimentés par l'IA
Un assistant de codage IA peut être compris comme un outil d'automatisation capable de terminer les tâches assignées par les développeurs. Le domaine de l'interaction homme-machine compte de nombreuses études sur ces outils ; le modèle de Trust, self-confidence and operators' adaptation to automation est particulièrement approprié pour expliquer le taux d'utilisation, défini ici comme le pourcentage de temps où les développeurs utilisent l'assistant par rapport à leur temps total de développement.
Quatre facteurs affectent ce taux : la confiance (le niveau de confiance des développeurs dans l'assistant, notable de 1 à 10 selon la perception subjective), la confiance en soi (la confiance des développeurs dans leurs propres capacités), le biais b (la tendance négative envers l'assistant, principalement déterminée par les expériences passées et l'environnement, plus b est élevé, plus la volonté d'utilisation est faible) et le paramètre de forme s (la force de l'attachement aux habitudes de travail existantes, plus s est large, plus la résistance au changement est grande).
Il est important de noter qu'un assistant de codage IA n'est pas un outil d'automatisation à fonction unique comme une touche de raccourci, mais un outil général capable de gérer toute tâche de programmation. Pour un même assistant, les paramètres du modèle varient donc selon les types de tâches : un développeur peut lui faire confiance pour générer des blocs de code sans lui faire confiance pour corriger des bogues ; être à l'aise pour implémenter une fonctionnalité dans une structure existante sans l'être pour refactoriser une architecture ; ou multiplier les essais sur ses projets personnels sans vouloir prendre les mêmes risques sur les projets commerciaux.
Éliminer le biais (b)
Le biais de chaque développeur varie. Certains sont très optimistes, disposés à tenter tout type de tâche sans que les échecs affectent leur attitude. D'autres sont très prudents, n'essayant qu'après des preuves d'efficacité sur le type de tâche concerné, et abandonnant rapidement en cas d'échec.
Pour éliminer le biais, il faut d'abord renforcer la motivation : intégrer la capacité à utiliser ces outils dans les évaluations de compétences, encourager les essais dans le travail quotidien, partager les histoires de succès, résumer les meilleures pratiques et résoudre les points douloureux de l'équipe.
Il faut ensuite reconnaître les coûts d'utilisation : rédiger des invites, examiner le code, corriger les erreurs et tester différentes approches demandent du temps et de l'effort, sans garantie de rendement, parfois plusieurs tentatives révèlent que l'assistant ne peut pas compléter la tâche. Si ces coûts ne sont pas reconnus, les développeurs les supportent seuls et deviennent de plus en plus hésitants.
Il faut enfin améliorer le partage d'informations dans l'équipe : contrairement aux IDE, les assistants n'ont pas de méthode d'utilisation fixe, et chacun peut découvrir des approches aux taux de réussite très variables. Collecter en continu les usages réussis ou échoués et promouvoir largement les pratiques efficaces est le meilleur moyen de réduire les biais.
Fournir plus d'informations pour calibrer la perception subjective
La confiance des développeurs et leur confiance en soi sont des perceptions subjectives. Nous devons fournir suffisamment d'informations pour objectiver l'efficacité de développement des assistants et celle des développeurs eux-mêmes.
Par exemple, nous pouvons identifier par des étiquettes les user stories et les commits réalisés avec l'aide d'un assistant, puis analyser séparément leurs métriques pour évaluer l'efficacité réelle apportée par l'outil.
Reste le levier principal : améliorer le niveau de confiance. Souvent réservée aux relations interpersonnelles, la notion de confiance a été étendue, dans l'interaction homme-machine, aux outils d'automatisation. Nous y consacrons la section suivante.
Un modèle de confiance pour les assistants de codage alimentés par l'IA
Qu'est-ce que la confiance ?
J'utilise la définition du document Trust in Automation : Designing for Appropriate Reliance : la confiance est l'attitude qu'un agent (comme un assistant de codage IA) aidera à atteindre les objectifs d'un individu dans une situation caractérisée par l'incertitude et la vulnérabilité.
Divers modèles décrivent les composantes de la confiance : compétence, intégrité, cohérence, loyauté et ouverture pour certains ; crédibilité, fiabilité et intimité pour d'autres ; capacité, bienveillance et intégrité pour d'autres encore. J'adopte ici le modèle du même document, qui la décompose en trois piliers : Confiance = Performance + Processus + Objectif.
Performance, processus, objectif
La performance recouvre la performance actuelle et historique de l'assistant, fiabilité, prévisibilité, capacité, dans des tâches concrètes : connaît-il le domaine et le contexte de la tâche du développeur, peut-il accomplir les tâches dans les délais prévus, avec la qualité attendue, et de manière reproductible sur des utilisations multiples ?
Le processus décrit comment l'assistant accomplit les tâches : pose-t-il de bonnes questions, fournit-il un plan détaillé avant l'implémentation, ses résultats correspondent-ils au plan annoncé, suit-il les meilleures pratiques et les instructions du développeur, respecte-t-il ses retours, permet-il l'interruption à tout moment, et dispose-t-il d'un mécanisme de contrôle des permissions bien conçu avec restauration facile de l'environnement ?
L'objectif mesure la cohérence entre l'intention de conception de l'outil et les buts du développeur : produit-il des hallucinations, garantit-il la sécurité des données et la conformité, se livre-t-il à des opérations malveillantes ou trompeuses, respecte-t-il réellement les objectifs du développeur ?
Modèle d'amélioration de la confiance pour les assistants de codage alimentés par l'IA
Avant de discuter du modèle d'amélioration de la confiance, nous devons classer les comportements erronés potentiels des assistants selon le modèle de comportement SRK (Compétence-Règle-Connaissance), afin d'analyser de manière ciblée les comportements qui affectent la confiance.
Classification des erreurs comportementales
Sur la base du modèle SRK, les erreurs des assistants se classent en trois catégories. Les oublis (compétence) : le comportement est correct mais mal exécuté, indiquer le besoin d'installer une dépendance mais générer une commande d'installation erronée, vouloir lire la sortie de ligne de commande sans y parvenir. Les erreurs basées sur les règles : le comportement est incorrect à cause de règles inadaptées, écrire le code avant les tests au lieu de suivre le TDD, entasser de la logique dans des modules existants au lieu d'en créer de nouveaux. Les erreurs basées sur la connaissance : il manque les règles ou connaissances nécessaires pour décider correctement, générer du code obsolète faute de connaître les dernières fonctionnalités du langage, mal comprendre la terminologie du projet.
Le modèle d'amélioration
Pour améliorer la confiance, il faut d'abord établir une équipe habilitante qui pousse l'ensemble du processus. Ensuite, visualiser la performance des assistants et des développeurs pour calibrer précisément les niveaux de confiance et de confiance en soi. Enfin, organiser des initiatives de partage de connaissances, sessions, formations, ateliers, playbooks, à tous les niveaux (entreprise, département, équipe) pour que chacun saisisse rapidement les stratégies IA de l'entreprise, les cas d'usage réussis ou échoués et les principes de fonctionnement des assistants.
Sur cette base, on adopte une démarche d'essai-erreur : expérimenter en continu, collecter les cas d'échec, identifier les comportements qui dégradent la confiance et les corriger. Chaque comportement identifié est analysé à la manière d'un diagramme d'Ishikawa pour remonter à la cause racine : un taux d'hallucination élevé signale un problème d'objectif, le non-respect du TDD un problème de processus, l'incapacité à lire une sortie de ligne de commande un problème de performance.
Les problèmes d'objectif relèvent de l'entreprise, car ils touchent à l'acquisition de l'outil : un taux d'hallucination élevé peut venir d'un contrat qui n'active pas les modèles avancés, une fuite de données de mécanismes de protection inadéquats. Les résoudre, mise à jour du contrat ou changement d'outil, a l'impact le plus fort sur la confiance. Les problèmes de processus relèvent de l'équipe, car les pratiques diffèrent d'une équipe à l'autre : ne pas suivre le TDD, générer du code sans explication ou sans plan préalable se corrige en complétant les compétences, règles ou connaissances manquantes, avec un impact modéré. Les problèmes de performance relèvent du développeur, car chacun fait face à des tâches différentes : incompréhension de la stack du projet, problème d'intégration du plugin de ligne de commande, génération de classes trop grandes, l'impact unitaire est plus faible, mais cumulatif.
Application du modèle d'amélioration de la confiance dans GitHub Copilot
Modèle d'instructions Copilot
Sur la base du modèle d'amélioration de la confiance, nous optimisons le comportement de GitHub Copilot selon trois dimensions, connaissance, règles et compétences, en concevant un modèle d'instructions Copilot structuré.
La connaissance aborde les erreurs basées sur la connaissance : quand nous en découvrons une, nous ajoutons la connaissance manquante à cette partie (architecture système, directives de codage, piles technologiques).
Les règles abordent les erreurs basées sur les règles : nous y ajoutons les règles applicables au scénario (définir les problèmes avant de les résoudre, créer des plans avant l'implémentation, utiliser le TDD pendant l'implémentation).
Les compétences abordent les oublis : nous y ajoutons les compétences manquantes (définition des problèmes, planification des solutions, compétences TDD).
Collaboration d'équipe
Ce modèle est principalement maintenu par le responsable IA de l'équipe, qui garantit l'alignement du processus de développement de GitHub Copilot avec les meilleures pratiques : définition des problèmes, planification, TDD, pensée à voix haute, exécution des tests et des commandes.
Le modèle est versionné dans le dépôt de code, pour que chaque membre adopte les meilleures pratiques en développant avec Copilot. Cela ne garantit pas la réussite de toutes les tâches, cela n'en augmente que la probabilité. Pour les tâches échouées, les développeurs analysent les raisons d'échec et complètent le modèle avec la connaissance, les règles ou les compétences manquantes, le transformant progressivement en instructions Copilot propres au dépôt.
Les responsables IA suivent les instructions de chaque dépôt, identifient les éléments largement réutilisés et les remontent dans le modèle commun. Grâce à cette méthode, la confiance de l'équipe dans GitHub Copilot augmente, et les taux d'utilisation avec elle.
Conclusion
Un assistant de codage alimenté par l'IA est comme un nouvel employé. Malgré des capacités potentiellement fortes, nous devons encore le former pour qu'il s'aligne avec nos valeurs, adhère à nos meilleures pratiques et apprenne les compétences requises. Ce n'est que lorsque nous avons pleinement confiance en lui que nous pouvons lui assigner des tâches importantes.
Disclaimer : Les déclarations et opinions exprimées dans cet article sont celles de l'auteur(es) et ne reflètent pas nécessairement les positions d'Adservio.
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
