7. L’IA dans le cycle de développement
Repères : enregistrement 41:00–48:20 et 73:00–74:30.
7.1. Une adoption rapide, mais différente selon les organisations
Pierre-Olivier raconte environ deux ans de transition chez GoTo. Au départ, des modèles peu coûteux servent à explorer le développement assisté et les résultats paraissent encore peu convaincants, presque une curiosité. Au moment de la conférence, l’IA est présente quotidiennement dans plusieurs étapes :
- comprendre et concevoir ce qui doit être fait;
- préparer les tickets;
- réaliser l’implémentation;
- produire ou examiner les tests;
- vérifier la qualité et les métriques.
Le changement porte donc sur le processus, au-delà de la complétion de quelques lignes. Pierre-Olivier précise cependant que l’adoption n’est pas uniforme. Certaines petites ou moyennes entreprises de son entourage explorent encore un usage à plus grande échelle, alors que beaucoup d’organisations qu’il observe avancent très vite. Ce retour d’expérience n’est pas une statistique représentative de toute l’industrie.
Patrick situe les débuts de son équipe en 2023 avec AWS CodeWhisperer, surtout pour la complétion, avant les assistants et agents plus avancés. Les deux récits montrent une évolution des usages plutôt qu’un passage instantané d’un outil inexistant à une délégation complète.
7.2. Le junior doit apprendre et décider, pas seulement générer
La rapidité des modèles augmente les attentes sur la quantité produite et les tickets réalisés. Mais cette vitesse crée un piège : donner une valeur apparente de production sans développer la compréhension. Pierre-Olivier insiste sur un plan avant l’exécution par l’agent et sur la compréhension de ce que la personne veut faire.
Un junior doit pouvoir progresser, poser des questions pertinentes et gagner de l’autonomie. L’entreprise ne cherche pas seulement une personne qui transmet chaque question à un modèle ou à un collègue et ferme des tickets en chaîne. Le développement du jugement reste une partie de sa contribution future.
L’IA peut aussi servir l’apprentissage : comprendre une nouvelle technologie, obtenir une définition, clarifier un attribut ou un comportement, se documenter et rédiger. Chez AXSO, des stagiaires ont accès aux outils, mais sont encouragés à ne pas s’y reposer systématiquement. Le recul d’un senior, devenu rapide avec l’expérience, n’est pas encore disponible de la même manière chez un junior.
La distinction est donc fonctionnelle : utiliser un outil pour apprendre et vérifier ne produit pas les mêmes effets que lui déléguer une tâche sans savoir ce qui a été décidé. Un même outil peut soutenir ou affaiblir le développement selon la démarche.
7.3. Liberté d’expérimenter et contraintes organisationnelles
Patrick décrit un milieu assez souple sur les outils et leur utilisation : les employés peuvent essayer, apprendre et parfois se tromper. Cette liberté reste à l’intérieur des politiques de conformité et des outils autorisés. Elle n’équivaut pas à une permission générale d’envoyer n’importe quelles données à n’importe quel service.
Il mentionne des restrictions sur des modèles comme DeepSeek et Kimi, puis des usages passant par OpenRouter avec des conditions de ZDR, c’est-à-dire d’absence de conservation des données, et d’hébergement au Canada. Il décrit le cadre de son organisation et les configurations qu’il rapporte. Ni le nom d’un intermédiaire ni l’étiquette ZDR ne prouvent, à eux seuls, une localisation ou une autorisation institutionnelle pour tout usage.
Le professeur rappelle également que certaines contraintes du MCN peuvent concerner l’Université. Ces propos sont importants pour distinguer l’usage professionnel décrit de ce qui est autorisé dans une activité universitaire. La conférence ne modifie pas les règles d’un cours ou d’une évaluation.
Patrick reconnaît une tension entre des personnes qui utilisent trop l’IA et d’autres trop peu. Il ne prétend pas connaître un optimum valable pour tous. L’environnement doit permettre d’apprendre tout en conservant une réflexion sur la tâche, les données, les contraintes et les effets de la délégation.
7.4. Des revues probabilistes aux règles déterministes
Les revues par IA peuvent découvrir de vrais problèmes, mais Patrick les trouve aussi parfois bruyantes et distrayantes. Son équipe cherche à transformer les remarques récurrentes en règles déterministes, notamment par le linting et des règles personnalisées au dépôt.
Un linter vérifie automatiquement des conventions que l’on sait formuler. Les exemples donnés sont une longueur maximale de 120 caractères par ligne et une convention de nommage comme camelCase. Ce sont des exemples de règles possibles, pas des normes imposées par cette semaine à tous les projets.
Le mécanisme comporte quatre étapes : convention explicite → contrôle automatique → retour immédiat → correction. Un agent peut exécuter le contrôle, constater l’écart et se corriger; un humain n’a plus à répéter la même remarque de forme. Patrick souligne un coût inférieur et moins de distractions en revue.
Cette automatisation est adaptée à ce qui se prête à une règle explicite. Elle ne démontre pas que toute décision d’architecture ou toute compréhension du besoin peut être remplacée par un linter. Son intérêt est de réserver davantage d’attention humaine aux questions qui demandent réellement du jugement.