En regardant où nous en sommes aujourd'hui dans mon entreprise et la façon dont nous utilisons l'IA, je pense qu'on peut dire que nous avons fait beaucoup de chemin et qu'il nous en reste encore beaucoup à faire. Mon propre usage a beaucoup changé depuis quelques années. J'ai commencé comme beaucoup de gens, en utilisant ChatGPT surtout pour coller des erreurs, poser des questions, puis faire des allers-retours jusqu'à obtenir quelque chose d'utile. Quand je regarde certains de mes premiers prompts maintenant, j'ai un peu l'impression de relire du code que j'écrivais quand j'ai commencé en 2003. Je vois ce que j'essayais de faire, mais je vois aussi tout ce que je ne comprenais pas encore.
Avec la vitesse à laquelle les outils et les façons attendues de travailler changent, je ne doute pas que je regarderai ce que je fais aujourd'hui dans un an et que je penserai encore la même chose. C'est une partie de ce qui rend le changement intéressant. Autour de moi, je vois une vraie différence entre les gens qui ont déjà été développeurs et ceux qui codent encore tous les jours. Je m'inclus maintenant dans le premier groupe. Pour nous, l'IA ramène un sentiment de création qui peut disparaître quand on s'éloigne du développement quotidien. Après assez de temps, bâtir quelque chose peut commencer à sembler trop long par rapport à tout le reste qu'on doit faire.
L'IA a changé ce sentiment pour moi. Au début, c'était surtout du débogage par copier-coller. Ensuite, c'est devenu de la planification, avec plus de contexte donné à l'outil, puis une partie plus grande de l'implémentation que je pouvais lui laisser faire pendant que je continuais d'autres tâches. Cette boucle de planification et de révision m'a redonné l'impression d'avoir le temps de coder. Je pouvais passer un plus petit bloc de temps concentré, laisser l'outil faire une partie du travail mécanique, puis revenir évaluer le résultat. Je reste prudent avec ça, parce que je ne dirais pas que tout ce que je construis de cette façon est prêt pour la production. Mais j'ai eu beaucoup de plaisir à le faire, et l'étendue de ce que j'ai pu bâtir est beaucoup plus grande que si j'avais dû tout faire manuellement.
Un des premiers patterns utiles a été de rassembler des données opérationnelles. J'ai construit des outils pour agréger les worklogs Jira avec les détails et commentaires des stories, autant dans Jira Cloud que dans notre Jira on-premise, les pull requests et leurs commentaires dans GitHub, ainsi que les informations de déploiement venant de Jenkins, AWS CodePipeline et Cloudflare. Tout cela s'est retrouvé dans une base SQLite locale qui est devenue utile pour plusieurs autres petits projets. Une fois ces données disponibles localement, il devenait beaucoup plus facile de bâtir des tableaux de bord, de répondre à des questions et de connecter des informations qui vivaient normalement dans des systèmes séparés.
Cela a mené naturellement à un tableau de bord sur l'adoption de l'IA dans notre équipe. Nous avions ajouté des champs dans Jira pour recueillir le feedback des développeurs sur la façon dont l'IA aidait ou nuisait à leur travail. J'ai aussi regardé combien de revues de pull requests étaient faites par l'IA en vérifiant l'utilisateur de revue dans GitHub, et j'ai commencé à construire des statistiques autour du moment des déploiements. Je voulais pousser cela vers des métriques de type DORA, dont le temps entre le premier worklog sur une fonctionnalité et sa date de déploiement. Une limite est devenue claire assez vite : nous n'avions pas une bonne façon structurée de suivre les bugs de production et leur résolution sans lire manuellement l'historique de chat. C'est encore quelque chose que je veux améliorer.
Certains projets étaient plus proches de l'automatisation. J'ai construit un flow d'on-call où un courriel reçu par AWS SES déclenchait une Lambda, la Lambda analysait le courriel avec le SDK d'OpenAI pour déterminer quelle équipe devait être alertée, puis elle créait un incident dans Datadog, qui déclenchait la bonne équipe dans Opsgenie. Les réponses au même courriel d'incident étaient ajoutées à l'incident existant tant qu'il était encore ouvert. J'ai aussi construit un outil local de sommaire hebdomadaire parce que nous devions envoyer des mises à jour sur ce que l'équipe avait fait. Il prenait les worklogs entre deux dates, ajoutait des informations que je fournissais manuellement, incluait les incidents arrivés pendant la semaine, puis envoyait le contexte combiné au SDK de Claude pour produire un courriel bien formaté. Je révisais encore le résultat manuellement et j'ajustais le texte, parce que l'outil présumait parfois trop de choses et je ne voulais pas envoyer la mauvaise information à notre board.
D'autres expériences servaient davantage à soutenir le leadership. Pour les revues trimestrielles, j'ai construit un outil qui analysait les pull requests, les changements de code, les commentaires de stories et les commentaires de pull requests pour chercher des patterns. Le but n'était pas de laisser l'IA évaluer les gens aveuglément. Le but était de faire ressortir du feedback récurrent ou des erreurs évitables pour que les leads aient de meilleurs intrants en préparant leurs revues. Cela fonctionnait bien dans certains cas, mais ça montrait aussi où les données étaient incomplètes. Les développeurs qui pairent beaucoup, ou les leads qui passent plus de temps à aider directement les autres, laissent moins de traces dans les logs que j'avais. Cela pouvait pousser l'analyse dans la mauvaise direction, ce qui est exactement pourquoi le résultat devait rester un intrant pour une conversation humaine plutôt que devenir la conversation elle-même.
J'ai aussi utilisé l'IA pour des tâches d'ingénierie plus directes. Un exemple était un script de sauvegarde pour un service tiers. Le fournisseur offre des sauvegardes, mais nous voulions avoir notre propre copie des données à l'extérieur de leur système parce que nous n'avons pas accès directement à leur processus de backup. Avec Claude, j'ai construit un script qui utilisait l'API pour télécharger les métadonnées, télécharger les médias, et pousser seulement les nouvelles données et les nouveaux médias vers S3. Je suis certain que j'aurais pu le faire sans IA, mais cela aurait pris plus de temps. Avec l'IA, c'était assez rapide pour transformer une tâche importante mais irritante en quelque chose de terminé.
Le projet le plus récent était lié à une exigence de conformité. Nous devions analyser une grande librairie vidéo pour détecter du contenu de choking en lien avec une nouvelle exigence au Royaume-Uni. Nous testions des fournisseurs qui utilisent l'IA pour détecter ce genre d'action, et j'avais reçu une liste de 95 vidéos avec des segments précis à tester. J'ai utilisé l'IA pour construire un outil en trois parties. D'abord, un script téléchargeait les vidéos sources depuis S3 et coupait les segments selon le CSV fourni. Ensuite, j'ai construit un tableau de bord pour voir chaque vidéo et chaque segment, et j'ai demandé à Claude d'implémenter l'API du fournisseur avec un flow de soumission manuelle et un historique des résultats. Une fois le flow manuel fonctionnel, je lui ai fait construire une pipeline qui soumettait tous les segments et collectait les résultats pour les faire apparaître dans l'interface.
Je pourrais continuer à donner des exemples, et c'est une partie du problème. J'ai maintenant un problème de structure de dossiers parce que j'ai tellement de petits projets que je ne me souviens plus de tous. Pour quelqu'un qui ne code pas tous les jours, c'est un changement important. La barrière pour bâtir un outil interne utile a assez baissé pour que des idées qui seraient restées dans la pile du "un jour" deviennent des prototypes fonctionnels. Certains restent des prototypes. Certains deviennent des outils que je réutilise. Certains m'apprennent simplement ce qu'il faudrait pour faire la chose correctement.
Pour les développeurs qui codent tous les jours, l'expérience est plus ancrée dans la réalité de leur travail. Ils comparent l'IA directement à ce qu'ils font déjà, et leurs inquiétudes sont plus précises. Dès le début, j'ai entendu des commentaires sur le trop grand volume de slop généré, sur des pull requests créées par des développeurs qui n'avaient pas vraiment vérifié le résultat, et sur du code qui avait l'air correct jusqu'à ce que quelqu'un qui connaissait le système le relise attentivement. Cette inquiétude est réelle. L'outil peut produire beaucoup, et il peut rendre le résultat convaincant même quand le développeur ne le comprend pas assez.
Ce sur quoi nous travaillons, c'est d'aider les développeurs à utiliser l'IA pour soutenir leur travail, pas pour remplacer leur responsabilité. Cette distinction compte parce que l'outil peut donner l'impression de presque tout faire. Il peut écrire du code, expliquer du code, créer des tests, refactoriser des fichiers et générer une pull request. Mais le développeur doit encore être responsable de ce qui est déployé. Cela veut dire éviter les pull requests avec des milliers de changements sans focus, s'assurer que la personne comprend le code qu'elle soumet, et continuer à apprendre de ce que l'IA produit plutôt que de le traiter comme une boîte noire.
Je pense que cette transition a été en grande partie réussie jusqu'ici. Les développeurs ont appris, au moins à haut niveau, à traiter l'IA comme un outil et non comme un remplacement. Mais un nouveau défi a commencé récemment quand on nous a demandé de réfléchir à un flow où le développeur serait surtout présent au début et à la fin, pendant que l'IA ferait une grande partie du travail entre les deux. Je pense que c'est possible avec le bon setup de projet, les bons outils et les bonnes attentes. Je ne pense pas que ce sera parfait, et je ne pense pas que cela devrait être construit comme un seul grand saut automatisé entre une idée et la production.
La façon dont je l'aborderais est itérative. Construire la pipeline comme un ensemble de modules. Améliorer chaque étape avec le temps. Rendre la demande initiale plus claire. Rendre la planification explicite. Rendre l'implémentation assez isolée pour être revue. Rendre les tests et les validations plus solides. Rendre la revue humaine finale incontournable. Différents types de demandes auront besoin de chemins différents, et la pipeline devrait s'améliorer à mesure que nous apprenons où elle échoue. Le risque est de déployer plus de bugs, ou de créer du code plus difficile à maintenir parce que la personne qui l'approuve ne comprend pas vraiment comment il a été produit. Ce risque doit être pris au sérieux.
En même temps, pousser dans cette direction semble être là où beaucoup d'entreprises vont. Ne pas l'expérimenter comporte aussi un risque. Si ces workflows commencent à créer un véritable avantage concurrentiel et que votre entreprise n'a pas appris comment ils fonctionnent, rattraper le retard plus tard pourrait être plus difficile. C'est le message que j'ai essayé de donner aux gens de mon équipe qui craignent qu'une pipeline fonctionnelle signifie qu'ils sont remplacés. Qu'on l'aime ou non, beaucoup de rôles et d'entreprises se dirigent vers ce type d'automatisation. La meilleure réponse est d'apprendre comment cela fonctionne, où cela aide, où cela casse, et quel jugement humain doit encore l'entourer.
Alors, du copier-coller d'erreurs dans ChatGPT à la réflexion sur des pipelines de livraison assistés par l'IA, nous avons fait beaucoup de chemin. Il nous en reste encore beaucoup à faire. Le chemin n'est pas simple parce que les outils changent constamment, les attentes changent avec eux, et les risques sont réels. Mais je trouve cela étrangement stimulant. Cela m'a redonné une partie du plaisir de construire, tout en forçant une conversation plus difficile sur la responsabilité, la qualité, et ce que le travail d'ingénierie devrait devenir quand l'IA peut faire une plus grande partie de la saisie.
- Patrick