10. L’IA renforce le besoin de comprendre et de vérifier
10.1 La trivialité de l’exemple ne décrit pas tout le métier
La salutation simplifiée permet de suivre le mécanisme dans le temps disponible. Dans un produit industriel, les fonctions triviales déjà disponibles en bibliothèque ne méritent pas nécessairement d’être redéveloppées. L’avantage compétitif vient souvent de problèmes nouveaux ou complexes et de la valeur que leur résolution apporte au client.
Le conférencier évoque des développements scientifiques issus d’environ deux années de recherche avec des spécialistes possédant un doctorat ou une maîtrise en mathématiques. Cette complexité est très différente de Toto; elle augmente l’importance des tests à plusieurs niveaux. Le volume exact de formules ou de pages, mal reconnu dans la transcription, n’est pas repris comme un chiffre établi.
10.2 Trois usages de l’IA à distinguer
La question finale sur l’IA amène une distinction entre :
- L’assistance au travail quotidien : synthétiser les nombreux courriels du matin, organiser une journée ou retrouver l’évolution d’un dossier client sur plusieurs années.
- L’assistance au développement : construire du code ou guider la réalisation d’une fonctionnalité.
- L’IA dans le produit : proposer des fonctions utilisant l’IA à l’intérieur du logiciel ou de ses interactions.
Ces catégories n’ont ni le même objectif ni le même rôle dans le travail. L’intervenant confirme que l’entreprise utilise l’IA et la juge importante pour rester compétitive, mais ne fournit pas un inventaire précis des fonctions IA déjà livrées dans Algosys Metallurgical Accountant.
Il estime l’adoption difficile à éviter et considère qu’ignorer cette évolution risque de faire perdre un avantage compétitif. Ce sont ses positions à la date de la conférence, et non une mesure universelle des gains de tous les outils ou de tous les projets.
10.3 L’expérience permet de guider et de contrôler le résultat
Pour une personne expérimentée, l’assistant peut être guidé comme une équipe : préciser le besoin, orienter la réalisation, lire le code et vérifier qu’il est correct. Christian Desrosiers rapporte avoir réalisé ainsi des fonctionnalités de bout en bout très rapidement, parfois en moins de temps que l’explication complète à une équipe. La possibilité de juger le résultat est une condition importante de ce gain.
Si l’on ne sait pas programmer, reconnaître les erreurs et comprendre les choix de conception devient beaucoup plus difficile. Une fonctionnalité peut sembler réussir tout en contenant une structure dangereuse. L’analogie de la séance est celle d’un robinet qui donne de l’eau alors que les tuyaux cachés sont installés de façon inadéquate. Un travail ultérieur perce ou rompt un tuyau mal placé et provoque une inondation. Le résultat visible immédiat ne suffit pas à attester une bonne conception.
Cette distinction prolonge le TDD : une réussite observée doit être interprétée selon ce qui a réellement été vérifié. La responsabilité professionnelle comprend l’évaluation du code et sa capacité à évoluer, pas seulement sa production.
10.4 Le contexte du code influence l’assistance
Selon l’expérience du conférencier, les outils fonctionnent bien sur une base moderne et structurée, plus moyennement dans certains départs de zéro, et beaucoup plus mal sur du code patrimonial mal organisé. Il conseille de clarifier et refactorer une base difficile avant d’accumuler de nouvelles fonctions. La séance ne présente pas une comparaison mesurée de modèles ou de produits d’IA; ces appréciations gardent leur contexte.
L’outil peut reproduire les pratiques qu’il voit. Si les responsabilités sont mélangées et le code copié à répétition, il risque d’ajouter les mêmes formes. Les copies et les ajouts grossissent la base, la compréhension exige davantage de contexte et l’assistant peut oublier des éléments ou halluciner. La détérioration peut ainsi s’amplifier au fil des demandes.
Les pratiques de séparation des responsabilités, de lisibilité, de refactoring et de test facilitent le travail aussi bien des humains que des machines. Le développement assisté n’abolit donc pas les principes étudiés : il donne une raison supplémentaire de disposer d’un code compréhensible et d’une protection pertinente.
10.5 La valeur professionnelle reste dans le jugement
La conclusion invite les futurs développeurs à se demander quelle valeur ils apportent s’ils sont incapables de comprendre ce que la machine produit. Le rôle ne se réduit pas à demander du code. Il repose aussi sur la définition du besoin, le choix des comportements, le diagnostic, la compréhension de la structure et la vérification des conséquences d’un changement.
La conférence rapproche ainsi la compétence technique et la responsabilité : il faut pouvoir distinguer une solution qui semble fonctionner d’une solution que l’on peut justifier, maintenir et faire évoluer.