L’IA aide vos équipes mais attention aux conclusions hâtives

Les tableaux de bord de codage de l’IA offrent une visibilité, mais pas de clarté

L’essor des outils de développement de logiciels assistés par l’IA, tels que GitHub Copilot, Faros AI et Windsurf, modifie le mode de fonctionnement des organisations d’ingénierie. Ces outils ne servent pas seulement à écrire du code plus rapidement, ils remodèlent la façon dont les équipes construisent, collaborent et livrent. Les entreprises utilisent désormais des tableaux de bord pour suivre l’utilisation de l’IA, en examinant des paramètres tels que le taux d’acceptation, l’adoption de l’outil par les développeurs et la façon dont les délais changent lorsque l’IA est impliquée.

Cette visibilité aide les équipes à voir la diffusion et la portée de ces outils. Matt Fisher, vice-président de l’ingénierie produit chez Vimeo, explique qu’ils ont adopté des métriques pour mieux comprendre les changements fondamentaux que les outils d’IA ont introduits dans leur flux de travail, non seulement pour mesurer la productivité, mais aussi pour suivre les améliorations de la qualité du code. Todd Willms, directeur de l’ingénierie chez Bynder, s’est appuyé sur le tableau de bord Copilot de Jellyfish pour résoudre les commentaires contradictoires de ses équipes. Certains disaient que Copilot n’était pas du tout utilisé. D’autres affirmaient le contraire. Le tableau de bord l’a aidé à aligner la perception avec la réalité et à justifier la poursuite de l’investissement.

Cependant, ces tableaux de bord montrent surtout l’adoption au niveau de la surface. Ils nous indiquent à quelle fréquence l’IA est utilisée, par qui et dans quels langages. Mais ils ne donnent pas une image complète de la situation, par exemple si le code est propre, s’il entraîne moins de pannes ou s’il a un impact sur la maintenance à long terme. Ces dirigeants ont constaté que la visibilité de l’utilisation des outils n’est qu’un point de départ. La connaissance de l’efficacité doit encore venir de questions qui vont au-delà du tableau de bord.

Si vous êtes un cadre dirigeant d’une entreprise technologique, sachez que ces tableaux de bord fournissent une information opérationnelle, et non une clarté commerciale. Utilisez-les pour comprendre l’adoption et l’engagement, mais pas pour prendre des décisions stratégiques de manière isolée. Vous aurez besoin de mesures plus approfondies du flux de travail et d’un bon dialogue interne pour lier l’utilisation à la valeur réelle.

Des mesures sans contexte peuvent fausser les objectifs de performance

Les chiffres relatifs à l’utilisation de l’IA, comme le nombre de suggestions de code acceptées par un développeur, sont intégrés dans les OKR et même dans les KPI. Ce n’est pas nécessairement une bonne décision. Le taux d’acceptation, bien que simple à suivre, est souvent pris pour un indicateur de performance significatif. Ce n’est pas le cas. Ce n’est pas parce qu’un ingénieur accepte du code généré par l’IA ne signifie pas qu’il s’agit d’un bon code ou même du bon code. Optimiser en fonction de cela invite à l’inefficacité.

Plusieurs responsables de l’ingénierie l’ont signalé très tôt. Un directeur de startup dans le domaine de la fintech a conseillé d’éloigner les discussions sur le retour sur investissement de l’IA des mesures de production telles que les lignes de code et de se concentrer plutôt sur la fréquence de déploiement, c’est-à-dire la fréquence à laquelle les mises à jour du produit sont livrées avec succès. Il a fait référence à la loi de Godhart, le principe selon lequel lorsque la mesure d’une chose devient un objectif en soi, elle perd de sa valeur. Ce principe s’applique directement ici. Si les développeurs sont jugés en fonction de la quantité de code d’IA qu’ils utilisent, ils en utiliseront davantage, que cela soit utile ou non.

Simon Lau, de ChargeLab, a utilisé les mesures de Windsurf pour atteindre des objectifs tels que 6 000 complétions de code au cours d’un trimestre, et il les a atteints. Mais d’autres restent plus prudents. Willms et Fisher ont tous deux déclaré qu’ils n’étaient pas à l’aise avec l’idée d’aligner les OKR ou les évaluations de performance sur les mesures d’utilisation de l’IA. Ils considèrent plutôt les données comme une perspective et non comme une prescription.

Si vous dirigez le produit ou l’ingénierie, ne confondez pas les tableaux de bord avec la stratégie. Utilisez les indicateurs d’utilisation de l’IA pour vérifier l’adoption. Pour tout le reste, utilisez des mesures d’impact plus larges, comme DORA, SPACE, la fréquence des livraisons et la fiabilité du système. Les résultats commerciaux dépendent des résultats et non des activités. Formez vos équipes à regarder au-delà des mesures de vanité et à se concentrer sur la création de valeur.

Les outils de codage de l’IA ont des retombées qualitatives, et non quantitatives.

Ce qui a été omis dans la plupart des discussions sur les outils d’IA pour les développeurs c’est l’endroit où la valeur réelle apparaît. Il ne s’agit pas seulement d’accélérer le code ou d’augmenter le nombre de suggestions acceptées. Ces mesures sont faciles à suivre, mais elles ne représentent pas l’impact réel. Le véritable gain réside dans la rapidité avec laquelle les ingénieurs peuvent comprendre des systèmes complexes et apporter une contribution significative, même lorsqu’ils sont nouveaux ou peu familiarisés avec la base de code.

Matt Fisher, de Vimeo, l’a clairement souligné. Les assistants de codage IA réduisent le temps nécessaire aux ingénieurs pour acquérir un contexte. Ils les aident à naviguer plus rapidement dans les zones de code qui ne leur sont pas familières, ce qui se traduit par des temps de montée en puissance plus courts pour les nouvelles recrues et par des transferts plus fluides entre les équipes. Pour les équipes qui s’occupent de systèmes existants ou de grande taille, cette réduction de la charge mentale est un véritable multiplicateur de performance. Elle accélère tout ce qui vient ensuite, la planification, la construction, les tests, le déploiement.

Todd Willms, de Bynder, a obtenu des résultats similaires. Les données d’utilisation ne validaient pas seulement l’adoption de l’outil, elles indiquaient le type de comportement de l’utilisateur qui reflétait la productivité en dehors des mesures habituelles. Les développeurs qui utilisaient efficacement Copilot n’inséraient pas aveuglément du code, ils avançaient plus rapidement dans les cycles de décision qui rendent l’ingénierie efficace.

Les dirigeants doivent être conscients que les flux de travail construits avec l’aide de l’IA évoluent. Les équipes ne se contentent pas d’écrire plus vite, elles pensent différemment. Cette différence n’apparaît pas toujours sur un tableau de bord. Le succès ne résultera pas du suivi des personnes qui utilisent le plus l’outil ; il viendra de la compréhension de la manière dont l’outil façonne la façon dont les problèmes sont résolus. Réfléchissez à la manière dont vos équipes s’inscrivent, collaborent et se déplacent dans les environnements. Si vous constatez une accélération mesurable au-delà de la génération de code, vous êtes sur la bonne voie.

La visibilité au niveau du flux de travail permet de prendre de meilleures décisions que les seules statistiques d’utilisation.

En se concentrant uniquement sur les mesures d’utilisation, on attire l’attention sur des actions isolées. Mais le développement, en particulier à grande échelle, dépend de systèmes d’actions. C’est là que les tableaux de bord intégrés tels que Faros AI commencent à apporter une réelle valeur ajoutée en matière de prise de décision. Ces plateformes ne se contentent pas d’indiquer qui a accepté quel code, elles montrent comment cette activité est liée à la production d’ingénierie à cycle complet.

Faros suit des éléments tels que la durée d’attente des tickets, le temps écoulé entre le raffinement et le déploiement, et l’évolution de ces étapes lorsque les développeurs utilisent des outils d’IA ou non. Matt Fisher a souligné que ces données sont bien plus importantes que les taux d’acceptation bruts. Elles révèlent comment l’IA modifie le débit réel. Ces informations aident les dirigeants à décider si la présence de l’IA accélère la livraison de manière significative, ce qui est important au niveau de l’organisation, et pas seulement au niveau de chaque développeur.

C’est sur ce point que les dirigeants doivent se concentrer. L’adoption de l’IA dans l’ingénierie logicielle n’est pas simplement un autre outil de productivité, elle transforme les flux de travail. Les dirigeants ne peuvent pas mesurer ce changement en se contentant de suivre l’achèvement de chaque code. Vous avez besoin d’outils qui associent l’utilisation de l’IA à des mesures de processus au niveau du système. Les délais des sprints s’améliorent-ils ? La boucle de rétroaction est-elle plus serrée ? Les cycles de révision sont-ils plus courts ?

Lorsque l’utilisation des outils d’IA est intégrée à vos données d’ingénierie de bout en bout, elle permet de savoir où l’on gagne ou perd du temps. Et c’est ce qui compte. Car une fois que vous avez aligné les données d’adoption avec les performances de livraison et que vous commencez à prendre des décisions sur ce qui fait réellement avancer le débit, vous n’êtes plus en train de deviner. Vous opérez avec un effet de levier.

Le partage des données d’utilisation de l’IA avec les développeurs favorise l’adoption et améliore la dynamique de l’équipe.

L’une des mesures les plus judicieuses prises par les responsables de l’ingénierie en ce qui concerne les tableaux de bord des outils d’IA consiste à donner aux développeurs l’accès à leurs propres données. Ce changement transforme les outils de suivi d’une surveillance managériale en un aperçu personnel. Les développeurs ne se sentent pas surveillés, mais informés. Cette distinction est importante. Elle renforce la confiance et aide les équipes à s’auto-optimiser sans pression extérieure.

Chez Bynder, Todd Willms a mis le tableau de bord Copilot à la disposition de tous les développeurs. Au lieu d’utiliser les données pour exercer une pression descendante, il a laissé les développeurs explorer leur propre utilisation et décider de la manière dont elle s’intègre dans leur charge de travail. Il en a résulté un dialogue constructif, et non une résistance. Dans un cas, un développeur senior qui avait initialement évité les outils d’IA a commencé à expérimenter après la mise à disposition de nouvelles fonctionnalités. Une fois que l’utilisation s’est intensifiée, ce développeur est devenu un utilisateur chevronné, ce qui a donné lieu à une conversation plus large sur les problèmes que l’outil était le mieux à même de résoudre.

Matt Fisher, de Vimeo, a ajouté que les utilisateurs expérimentés jouent un rôle clé dans l’adoption des outils. Ces personnes ne se contentent pas d’utiliser les outils, elles adaptent leur flux de travail de manière efficace et obtiennent des résultats que les autres remarquent. Et parce qu’ils sont des pairs, on leur fait davantage confiance. Leur expérience directe a du poids, bien plus que n’importe quelle formation centralisée ou que n’importe quel encouragement de la part de la direction.

Pour les dirigeants, cette dynamique est importante. Lorsque les développeurs peuvent consulter leurs propres données, ils sont plus enclins à expérimenter, à partager leurs succès et à faire progresser collectivement les meilleures pratiques. Cela renforce la culture autour de l’apprentissage continu plutôt que de l’application descendante. Plutôt que de normaliser la productivité par le biais d’un ensemble d’objectifs rigides, le partage des données d’utilisation de l’IA de cette manière encourage l’adoption par le biais de preuves, de résultats et de mentorat par les pairs.

C’est le modèle qui s’adapte. Et c’est celui qui crée un environnement de confiance où les outils d’IA ne se sentent pas imposés, mais utiles. À partir de là, de meilleures performances s’ensuivent, sans qu’il soit nécessaire d’en faire une question de conformité.

Principaux enseignements pour les dirigeants

• Visibilité ≠ impact : Les tableaux de bord de codage de l’IA montrent l’utilisation, et non l’efficacité. Les dirigeants devraient utiliser ces données pour suivre les tendances d’adoption, et non pour définir les performances ou faire des hypothèses de retour sur investissement de manière isolée.
• Méfiez-vous des indicateurs de vanité : Des mesures telles que le taux d’acceptation peuvent fausser les objectifs et encourager des comportements contre-productifs. Donnez la priorité au débit, à la durée du cycle et aux résultats du produit plutôt qu’aux statistiques d’utilisation brutes.
• La valeur vit dans le contexte : Les gains les plus significatifs des outils d’IA sont qualitatifs, comme la vitesse d’intégration et une compréhension plus rapide des bases de code complexes. Souvent, ces améliorations n’apparaissent pas dans les données de surface, mais elles favorisent l’efficacité à long terme.
• Mesurez le flux de travail, pas seulement les données d’entrée : Les mesures d’utilisation déconnectées des performances de développement de bout en bout n’ont qu’une valeur limitée. Les dirigeants devraient intégrer les données d’utilisation de l’IA à des mesures plus larges du flux de travail pour avoir une idée de l’impact réel sur la livraison.
• L’autonomisation favorise l’adoption : Donner aux développeurs l’accès à leurs propres données d’utilisation de l’IA permet d’instaurer un climat de confiance et d’encourager un engagement significatif. Les équipes apprennent plus rapidement lorsque l’adoption se fait par les pairs plutôt que par le haut.