J'ai donné une présentation intitulée Leveraging AI in Development Workflows devant 47 ingénieurs chez BMO. Le sujet portait sur la configuration des garde-fous et les standards de qualité de code en entreprise, et elle s'est terminée par une séance de questions ouverte. Présenter des outils de code IA dans une banque réglementée demande plus que des démonstrations de capacités. Ça demande de reconnaître les craintes que les gens ne diront pas à voix haute, les effectifs, le savoir-faire, la précision, et de montrer les garde-fous qui rendent l'outil compatible avec l'environnement.
J'écris ceci de mémoire et à partir de mes propres notes, pas d'un enregistrement. Lisez donc la structure ci-dessous comme la forme de la session plutôt que comme une transcription. Ce sur quoi je peux être précis, c'est le raisonnement : pourquoi j'ai choisi ce sujet, quelles démonstrations valent le temps qu'elles prennent, quelles objections méritent une vraie réponse, et ce que je changerais si je recommençais.
Pourquoi c'est moi qui ai porté cette initiative
On ne m'a pas assigné ça. Je l'ai proposé parce que j'utilisais des outils IA tous les jours dans mon propre travail Angular depuis des années, que j'avais configuré l'assistant de mon équipe, GitHub Copilot Business, avec des garde-fous, et que j'avais accompagné les développeurs de mon équipe dans son utilisation. La différence de productivité était assez grande pour qu'il me semble déplacé de la garder dans une équipe de cinq. Des gens que je respectais passaient des après-midis sur du travail que l'outil règle en quelques secondes.
L'autre motivation était plus pragmatique. L'adoption de l'IA dans les grandes organisations tend à se faire de deux manières : des mandats top-down qui créent de la conformité sans adoption réelle, ou une diffusion bottom-up organique qui est lente et non coordonnée. Une vitrine structurée qui reconnaissait les vraies préoccupations tout en démontrant une vraie valeur semblait un chemin plus rapide vers le résultat que je voulais : des équipes utilisant ces outils efficacement et en toute sécurité.
Choisir le sujet
L'essentiel de la préparation est allé à trois choses : comprendre ce qui inquiétait réellement l'audience, choisir des démonstrations crédibles pour des développeurs expérimentés, et anticiper les objections assez bien pour y répondre honnêtement. La partie capacités était la partie facile. N'importe qui peut rendre un assistant IA impressionnant pendant dix minutes.
Je n'ai pas fait de sondage, et je n'en aurais pas tiré grand-chose de toute façon. J'y suis allé avec les préoccupations que j'avais entendues dans les conversations générales sur ces outils et celles que j'avais eues moi-même : le risque de sécurité et de conformité, la qualité et l'exactitude du code, et une plus personnelle que j'ai décidé de traiter à part. Le soupçon qu'un intérêt pour l'outillage IA soit en réalité un intérêt pour faire le même travail avec moins de monde.
Aborder la peur des réductions d'effectifs en premier
J'ai mis la question des effectifs dans l'ouverture plutôt que de la laisser couver sous la séance de questions en attendant qu'on la pose. Le cadrage que j'ai utilisé : je ne peux parler des plans à long terme de personne, mais ma position est que ces outils concernent la qualité et l'impact du travail, pas le remplacement des gens qui le font. Le jugement, la connaissance du domaine et la compréhension des systèmes ne s'automatisent pas. Ce qui s'automatise, c'est le travail que personne n'aime.
Je garderais cet ordre. Une préoccupation de cette taille colore tout ce qui se dit ensuite, et une salle qui soupçonne un agenda caché ne pose pas de vraies questions quand on ouvre le micro. Dites-le à voix haute avant la première démo, ou passez le reste de la session à parler à côté.
Comment je structurerais la session
La structure qui vaut la peine d'être gardée : un cadrage court, la majeure partie du temps en démonstrations en direct, une présentation des garde-fous, puis des questions ouvertes sans fin fixée. Gardez le nombre de diapositives bas. Les ingénieurs n'ont pas besoin d'un diaporama. Ils ont besoin de voir du code fonctionnel apparaître, puis de vous voir le vérifier.
- Cadrage : ce que la session couvre, ce qu'elle ne couvre pas, et la question des effectifs abordée d'entrée
- Génération de tests : donner à l'assistant une fonction aux cas limites pénibles et construire la suite en direct
- Un refactoring mécanique : une migration de pattern que tout le monde dans la salle a déjà faite à la main
- Une séance de débogage : décrire un bogue de concurrence à l'assistant et parcourir son analyse à voix haute
- Garde-fous : la configuration Copilot Business, les custom instructions du dépôt, et le pipeline qui rejette le mauvais code peu importe qui l'a écrit
- Questions ouvertes, sans heure de fin fixée
Les démonstrations qui portent
La génération de tests est celle qui porte. Prenez une fonction avec un ensemble de cas limites embrouillé, décrivez-la, demandez une suite, et le fichier revient en moins d'une minute avec des cas frontières qu'un développeur sous pression de délai aurait sautés. C'est la capacité la moins spectaculaire de la liste et la plus convaincante, parce que tout le monde dans la salle a déjà repoussé l'écriture exactement de ce fichier.
Utilisez du code dont l'audience reconnaît la forme. Pas du code du dépôt qu'elle a sous les yeux, ce qui soulève ses propres questions dans une banque et ouvre une conversation dont vous ne voulez pas au milieu d'une démo, mais le même framework, les mêmes conventions, le même genre de fonction qu'elle a touchée la semaine dernière. Un exemple jouet tiré d'un tutoriel se lit comme un argumentaire de vente et se fait traiter comme tel.
La démonstration de débogage est la deuxième plus forte. Une condition de course est un bon candidat : deux requêtes concurrentes où le résultat doit refléter la dernière initiée, pas la dernière résolue. Montrez le bogue, décrivez-le en langage simple, et parcourez l'analyse à voix haute. Ça arrive vite à switchMap. Ce qui est montré n'est pas la réponse, c'est la vitesse à laquelle on arrive à une hypothèse qui vaut la peine d'être testée.
La démonstration qui tombe à plat
Générer un composant à partir de zéro, c'est la démo faible. Le résultat est correct et les développeurs expérimentés restent de marbre, parce qu'ils peuvent écrire ce composant en cinq minutes de toute façon. J'avais mal évalué la proposition de valeur. La vitesse de scaffolding compte quand on génère beaucoup de composants d'un coup, ou quand le scaffolding est réellement compliqué. Pour un seul composant simple, c'est une erreur d'arrondi.
Je la remplacerais par de la revue de code assistée par IA. Lancer Copilot code review sur une pull request, puis comparer ce qu'il a signalé à ce que les reviewers humains ont signalé. C'est le cas d'usage qui surprend les développeurs expérimentés, parce qu'il fait remonter les problèmes qu'ils attraperaient à une deuxième lecture et qu'ils ratent à la première, sous pression de temps.
Les objections auxquelles il vaut la peine de se préparer
La séance de questions est là où le vrai travail se fait. J'étais préparé pour les questions de sécurité et de conformité : elles sont venues, et j'avais de bonnes réponses. Les deux objections pour lesquelles j'étais mal préparé ne portaient pas du tout sur la sécurité.
La première est l'objection du savoir-faire : générer du code plutôt que l'écrire produit des développeurs qui comprennent moins profondément leurs systèmes avec le temps. Celle-là n'a pas tort, et elle mérite une vraie réponse plutôt qu'un revers de main. Le même argument a été avancé pour les IDE, pour les frameworks, pour le copier-coller depuis StackOverflow, et chaque fois la réponse n'était pas de refuser l'outil mais d'être délibéré sur quand l'utiliser et quand écrire à partir de zéro pour construire ou garder la compréhension. Dites clairement que c'est un risque réel, parce que ça l'est.
La deuxième est l'objection de la précision. Ça se trompe. Oui, ça se trompe. La sortie de l'IA exige une revue, toujours. Le gain, c'est de générer un premier brouillon en trente secondes qu'un développeur senior revoit et ajuste ensuite, au lieu de taper ce brouillon soi-même. Livrez de la sortie IA sans revue et vous allez le regretter, et c'est un problème de workflow, pas un problème d'outil.
Ce qui fait vraiment bouger un sceptique
Si l'objection porte sur la sécurité, la présentation des garde-fous est la partie qui compte. Voir les règles écrites noir sur blanc sous forme de custom instructions Copilot concrètes, et voir le quality gate CI qui rejette le code peu importe qui ou quoi l'a écrit, fait passer le cadre de 'cet outil est un risque' à 'cet outil peut être configuré et encadré'.
Si l'objection porte sur la qualité, montrez l'outil en train de se tromper. Posez une question de suivi qui l'entraîne sur un mauvais chemin de diagnostic, repérez l'erreur dans son raisonnement à voix haute, et corrigez-la. Une démo où tout fonctionne est un argumentaire de vente. Une démo où vous attrapez l'erreur fait passer le vrai message : la compétence de revue reste la vôtre, et la vitesse de l'IA plus la revue senior bat l'une ou l'autre seule.
Ce qui a changé après
Je n'ai pas fait de mesure formelle de l'adoption, et c'est la première lacune que je comblerais. J'ai eu des conversations de suivi, pas un tableau de bord. Je ne peux donc pas vous dire ce qu'une seule session a changé chez 47 personnes, et quiconque vous tend un chiffre d'adoption bien propre après une seule présentation est en train de deviner.
- Dans mon équipe, rien n'a eu à changer : l'assistant était déjà configuré avec des garde-fous et les développeurs étaient formés. La présentation a surtout donné plus de légitimité à ce workflow
- Cette équipe a terminé le développement d'un projet de conformité AML avec environ 35 % d'avance sur le calendrier
- Au-delà de mon équipe, j'ai partagé le fichier de custom instructions avec quiconque le demandait. Plusieurs participants sont revenus avec des questions sur son adaptation à leurs propres dépôts, ce qui était le signal qui m'importait
- Ce que je n'ai pas, c'est un chiffre d'adoption à l'échelle de l'organisation. J'ai eu des conversations, pas un tableau de bord, et je m'entendrais sur une mesure légère avant la session la prochaine fois
Leçons pour quiconque pilote l'adoption de l'IA en ingénierie
Le processus m'a appris davantage sur la gestion du changement que sur l'IA. Les personnes techniquement sophistiquées n'ont pas besoin qu'on leur vende une capacité : elles ont besoin que leurs préoccupations soient abordées honnêtement. Le chemin vers l'adoption passe par reconnaître les risques légitimes, démontrer que ces risques peuvent être gérés, et montrer la valeur avec du code qu'ils reconnaissent de leur propre travail.
- Utiliser du code qui ressemble au travail de l'audience : un exemple de tutoriel se lit comme un argumentaire de vente
- Aborder la préoccupation des effectifs explicitement et tôt : elle colore tout le reste si elle n'est pas traitée
- Montrer l'IA se tromper et la récupération : ça construit plus de confiance qu'un résultat sans faute
- Apporter la configuration des garde-fous et le quality gate CI, pas seulement la capacité : en environnement réglementé, la couche de sécurité est la moitié intéressante
- Laisser les questions durer longtemps : les vraies questions, les vraies objections et le vrai intérêt émergent après la fin du contenu préparé
- Amorcer le suivi en trouvant deux ou trois participants engagés et en leur donnant quelque chose de précis à essayer dans la semaine
- Décider avant la session comment vous saurez que ça a fonctionné : je me suis appuyé sur les conversations après coup, et même un suivi en trois questions aurait rendu l'argumentaire pour la session suivante plus facile
Le but d'une vitrine n'est pas de générer de l'enthousiasme. C'est d'abaisser l'énergie d'activation pour les gens qui sont déjà curieux mais n'ont pas encore agi. On n'a pas besoin de convaincre tout le monde dans la salle. On a besoin de donner aux intéressés les outils et la confiance pour essayer.
Si vous êtes un ingénieur senior ou un tech lead qui envisage une initiative similaire dans votre organisation, mon conseil le plus fort est de commencer avec les gens qui sont déjà curieux. Trouvez trois ingénieurs qui ont exprimé un intérêt pour les outils IA, travaillez avec eux pendant deux semaines, documentez ce qu'ils apprennent, puis apportez cette expérience combinée à un groupe plus large. Les preuves par les pairs sont plus persuasives qu'une vitrine par un seul avocat. C'est la seule chose que je ferais différemment : j'aurais eu des co-présentateurs d'autres équipes plutôt que de présenter seul.
Références
- GitHub Copilot repository custom instructions. https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions
- GitHub Copilot. https://github.com/features/copilot