Un assistant de développement propose une modification ; une personne l'accepte, la fusionne et en prend la responsabilité. Cette chaîne de responsabilité reste inchangée même si l'auteur de la modification change, et c'est tant mieux : c'est le seul moyen de garantir qu'il y aura toujours quelqu'un à qui s'adresser en cas de problème inattendu du système en production.
Le problème survient lorsque la responsabilité est implicitement diluée, sans que personne ne le décide explicitement. Personne ne déclare ne plus être responsable de son code. En clair, le fossé se creuse entre ceux qui l'acceptent et ceux qui le comprennent.
Cette confusion est coûteuse car elle absorbe le budget et nuit à la crédibilité de l'initiative. Six mois plus tard, lorsqu'on demande ce qui s'est amélioré, la réponse honnête est généralement « l'expérience initiale », ce qui ne justifie pas un programme de transformation.
Trois mécanismes, tous trois silencieux :
L'évaluation devient superficielle. Lorsque des changements importants surviennent fréquemment, l'attitude du réviseur passe de « Je comprends et j'approuve » à « Cela semble raisonnable ». Le rapport DORA 2024 a mesuré l'effet global : à mesure que l'adoption de l'IA augmentait, la stabilité de la livraison diminuait de 7,21 TP3T, en lien avec l'augmentation de la taille des lots de modifications.
La notion d'auteur devient floue. Dans un cas précis, à la question « Qui a écrit ceci ? », on répond « Nous l'avons généré ». Cette réponse empêche la conversation de se poursuivre.
La confiance remplace la vérification. Le code fonctionne en phase de test, on suppose donc qu'il est bon. Mais fonctionner et être bon sont deux choses différentes : ce dernier point inclut la prise en compte du comportement du code lorsque le contexte change.
Dans le même rapport DORA, 39,21 % des développeurs ont déclaré avoir peu ou pas confiance dans le code généré. Ce constat est troublant : malgré une méfiance affichée, le volume de code accepté ne cesse d’augmenter.
Il ne s'agit pas de désigner des coupables. Il s'agit de la capacité à répondre à quatre questions concernant n'importe quelle partie du système :
Quiconque peut répondre aux quatre questions est responsable du code, qu'il ait été écrit par une personne ou un outil. Quiconque ne peut répondre à aucune d'entre elles n'est pas responsable, même s'il figure parmi les auteurs du dépôt.
Rôle | Que propose cet outil ? | Ce qui reste humain |
|---|---|---|
Conception | Alternatives et exemples | Choisir et accepter le choix |
Mise en œuvre | Projet fonctionnel | Vérifiez qu'il répond aux attentes de l'entreprise. |
Révision | Détection de motifs connus | Jugement sur l'aptitude et ses conséquences |
Opération | Alertes et diagnostic | Décider quoi faire lorsqu'un problème survient |
Responsabilité | Aucun | Tous |
Cette dernière phrase n'est pas rhétorique. Aucun outil ne partage la responsabilité devant un client, un auditeur ou un tribunal. L'organisation est responsable du fonctionnement de son logiciel, indépendamment de son mode de développement, comme l'a établi l'affaire du chatbot d'Air Canada, résolue en 2024.
On ne fusionne pas ce qu'on ne peut expliquer. La règle de base. Elle ne nécessite pas de comprendre chaque détail, mais plutôt de pouvoir répondre aux quatre questions ci-dessus.
Chaque changement a un responsable nommé. Pas une équipe. Une seule personne responsable de cette partie du système et à qui l'on peut poser des questions.
Les tests critiques sont rédigés par une seule personne. Si le même outil génère à la fois l'implémentation et le test qui la valide, le circuit se ferme sur lui-même et ne vérifie rien de pertinent.
L'ampleur du changement est limitée. C'est cette mesure qui rend les trois précédentes possibles. Un changement majeur ne peut faire l'objet d'un examen exhaustif, quelles que soient les bonnes intentions de l'examinateur.
Si votre entreprise externalise le développement, cette conversation a un impact contractuel direct. Trois questions à poser au prestataire :
Qui est responsable des défauts du code livré ? Un défaut ne constitue pas une modification du périmètre du projet. Il doit être corrigé gratuitement et documenté par écrit. Dans notre cas, il s'agit de la Garantie Rain : nous corrigeons à vie tout défaut du code que nous livrons.
Pouvez-vous expliquer n'importe quel aspect du système six mois plus tard ? Le test est simple : demandez une explication sur un module choisi au hasard.
Quels documents décisionnels sont fournis ? Il ne s'agit pas d'un commentaire ligne par ligne, mais plutôt d'expliquer pourquoi chaque approche a été choisie et laquelle a été écartée. C'est ce qui permet à une autre équipe de prendre le relais.
Un fournisseur qui accepte ces trois conditions affirme maintenir l'intégrité de la chaîne de responsabilité. Celui qui les nuance indique où se situe la faille.
Pour un directeur technique qui souhaite connaître l'état actuel de son équipe, il existe un exercice qui dure une heure : Choisissez au hasard trois parties du système et demandez aux responsables de répondre aux quatre questions..
Ce résultat ne mesure pas la qualité du code. Il mesure quelque chose de plus important : si l’organisation contrôle son système ou s’il en est simplement propriétaire.
La personne qui l'accepte et l'intègre au système, ainsi que l'organisation qui le met en production, sont responsables. Aucun outil ne partage cette responsabilité devant un client, un auditeur ou un tribunal : l'entreprise est responsable du fonctionnement de son logiciel, indépendamment de son mode de production.
Quatre questions essentielles se posent : quel est l’impact de cette solution sur l’activité ? Pourquoi est-elle conçue ainsi ? Quelle alternative a été écartée ? Quelles conséquences une modification entraînera-t-elle ? Et comment s’assurer de son bon fonctionnement continu ? Quiconque peut répondre à ces quatre questions est responsable du code, qu’il ait été écrit par une personne ou un outil.
Par trois voies silencieuses : la revue devient superficielle à mesure que les changements prennent de l’ampleur, la paternité des faits s’estompe jusqu’à ce que la réponse à un incident soit « nous l’avons généré », et la confiance dans la réussite des tests remplace la vérification que le comportement correspond aux attentes de l’entreprise.
Quatre : personne ne fusionne ce qu'il ne peut expliquer, chaque modification a une personne nommée responsable et non une équipe, les tests critiques sont écrits par une personne et non par le même outil qui a généré l'implémentation, et la taille des modifications est limitée afin que la revue soit possible.
Ils doivent être responsables des défauts du code livré, sans frais et par écrit, être capables d'expliquer n'importe quelle partie du système six mois plus tard et fournir une documentation des décisions prises et des alternatives écartées, et non pas seulement des commentaires dans le code.
D'après le rapport DORA de 2024, 39,21 % des personnes interrogées ont exprimé peu ou pas confiance dans le système. Ce constat est pertinent car il coïncide avec une augmentation du nombre de tests acceptés, ce qui laisse penser que la méfiance exprimée ne se traduit pas toujours par une augmentation du nombre de tests effectués.
Votre équipe pourrait-elle expliquer une partie quelconque de votre système ? Notre audit technique évalue l'architecture, le code, la dette technique et la maintenabilité réelle, par écrit et sous 10 jours ouvrables. Demander l'audit → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
