8. Comprendre, vérifier et conserver la maîtrise du travail

8. Comprendre, vérifier et conserver la maîtrise du travail

Repères : question vers 49:00, réponses 50:00–54:40; plaisir du métier et expérimentation 72:00–78:10.

8.1. La vitesse déplace le coût vers la revue

Une question pose un problème précis : où arrêter la délégation lorsqu’on comprend le principe général du code, mais pas ce qui se passe réellement dans son implémentation? Les invités reconnaissent que la difficulté concerne tous les niveaux, pas seulement les juniors.

Plus l’on génère rapidement, plus il faut valider et comprendre ce qui a été produit. Pierre-Olivier illustre cette charge par des modifications de 90 fichiers et 5 000 lignes. La quantité de code peut augmenter bien plus vite que la capacité humaine à le relire. La vitesse de production n’est donc pas, à elle seule, une mesure du progrès accompli.

Les moyens proposés sont cohérents avec cette limite : savoir où l’on va avant de solliciter l’agent, établir un plan, utiliser des garde-fous automatisés et parfois travailler sans génération pour conserver un apprentissage réel. Les intervenants ne donnent pas de seuil magique de compréhension suffisante et soulignent que la question évoluera avec les outils.

8.2. Diff et histoire Git : rendre le changement révisable

Patrick donne un indicateur simple : la taille du diff, c’est-à-dire l’ensemble des ajouts et suppressions entre versions. Face à une PR de 30 000 différences, il demande de la découper. Il préfère rendre la revue possible plutôt que prétendre comprendre un changement trop volumineux.

Il présente aussi l’historique Git comme une histoire faite de chapitres. Des commits itératifs et suffisamment petits aident à comprendre ce qui a été fait et pourquoi. Un grand nombre de commits sur une même branche peut être le signe d’un périmètre trop vaste : terminer une unité, l’intégrer, puis repartir peut alors être préférable.

Le nombre de cinquante commits est cité comme un signal possible de questionnement, pas comme une limite obligatoire. De même, les exemples de milliers de lignes ne constituent pas des seuils universels. L’idée est la lisibilité du changement et de sa progression.

Le bénéfice s’étend au-delà du collègue qui relit aujourd’hui. On peut devoir revenir sur son propre travail trois ans plus tard. Un historique pollué, mal expliqué ou rempli de changements sans séparation rend alors la maintenance difficile. L’organisation du travail est donc une manière de conserver la compréhension dans le temps.

8.3. Comprendre d’abord le problème et ce qui en détermine le résultat

Patrick insiste sur la maîtrise du problème à résoudre. Sans elle, il faut poser des questions; le fait qu’un agent produise une implémentation ne la remplace pas. La compréhension requise ne se répartit cependant pas uniformément sur toutes les lignes.

Dans son travail de maîtrise sur les données, il porte particulièrement attention à l’extraction, aux transformations, au nettoyage et à l’enrichissement. Ces opérations déterminent le sens et la qualité des données obtenues. Il peut accorder moins d’importance à un choix entre deux bibliothèques interchangeables qu’aux règles de transformation qui modifient le résultat.

Il s’agit d’un jugement selon les enjeux, sans autorisation générale d’ignorer le code. Les connaissances de conception, de qualité et de métriques aident précisément à distinguer une décision structurelle d’un détail secondaire, à guider l’agent et à évaluer son résultat. Le rôle de la formation est repris au § 10.

8.4. Gagner du temps ne supprime pas les coûts humains

Patrick décrit un bénéfice tangible : déléguer une correction de traduction ou produire un premier inventaire de règles de langue française lui laisse davantage de temps pour des problèmes qui l’intéressent, comme un système financier critique. Pour les règles, il précise qu’elles sont ensuite validées une à une. L’IA fournit un premier jet; elle n’atteste pas sa conformité.

Pierre-Olivier décrit aussi des preuves de concept produites très rapidement, ce qui peut être stimulant. En contrepartie, il constate davantage de revue, une charge cognitive accrue, un sentiment d’appropriation plus faible et parfois une compréhension globale moindre de l’application. Certains développeurs vivent un deuil d’une partie de l’acte de coder.

Il dit que l’ancienne manière de coder lui manque parfois et juge un retour en arrière peu probable. Ce sont des appréciations personnelles. Elles montrent que le plaisir du métier ne se résume pas au nombre de fonctionnalités produites, même si les gains de vitesse sont réels dans son expérience.

Le travail reste également social : planification, coordination interéquipes et ajustements occupaient déjà une place importante avant les agents. La transformation de l’écriture du code ne transforme donc pas tout le métier en un simple échange de demandes avec un modèle.

8.5. Réinvestir le gain dans l’analyse et l’apprentissage

Patrick donne l’exemple d’une dizaine d’algorithmes de gestion de trajets. Des premiers essais qui auraient pu demander environ deux mois pourraient, selon son estimation, être obtenus en un ou deux jours. Ce n’est pas une mesure contrôlée de productivité; c’est une illustration de l’accélération du premier jet.

Le temps dégagé doit servir à analyser ce qui se passe. Obtenir plusieurs solutions rapidement n’établit pas qu’elles résolvent correctement le besoin ou qu’elles sont prêtes à livrer. L’expérimentation plus accessible a de la valeur lorsqu’elle permet de mieux comparer et comprendre.

Marceau rapproche ce droit d’itérer d’une différence entre études et travail. Une ancienne étudiante lui avait dit trouver le bac plus difficile et l’emploi plus agréable. Il l’explique en partie par des critères différents : note et réussite d’un cours d’un côté, recherche de solution par essais, consultation et réutilisation de l’existant de l’autre. Le témoignage ne change pas les règles d’aide ou d’évaluation universitaires.

Enfin, le secteur décrit combine des périodes où l’on travaille fort, notamment lors des livraisons et mises en service, et la célébration des réussites collectives. Le plaisir et la convivialité ne signifient pas l’absence d’exigence; ils s’inscrivent dans une culture d’équipe et dans le sens donné au travail.