Développement agile avec juristes et programmeurs

À ce stade du guide, vous devriez avoir configuré l’environnement technique du projet et être prêt à commencer à développer en Catala. Mais même si ce n’est pas le cas, et avant de commencer à traduire votre premier texte juridique en code, vous devriez également mettre en place une organisation et une méthodologie appropriées pour vous assurer que vos efforts de traduction sont aussi productifs que possible, et conduisent au code avec le moins de bugs possible du premier coup. Cette section fournit des conseils et des justifications pour certaines des décisions de projet les plus importantes que vous aurez à prendre. De plus, elle donne des indications pratiques sur la façon d’ adapter la méthodologie agile de programmation à la tâche de traduire la loi en code, ce qui nécessite une culture de sécurité avant tout et un environnement organisationnel.

Pourquoi vous devriez éviter d’écrire des documents de spécification intermédiaires

Un trope courant des grandes organisations chargées d’automatiser la prise de décision basée sur des spécifications juridiques est de produire divers documents textuels servant de “spécifications” qui se situent entre les textes juridiques sources et le code exécutable automatisant les décisions.

Maintenant, chaque document s’appuie sur le précédent en allant plus en détail et en prenant de plus en plus de micro-décisions sur la façon dont la prestation doit être calculée. Ces micro-décisions sont cruciales et elles doivent être prises à chaque niveau avec le bon niveau de responsabilité quant aux effets de ces décisions sur les futurs bénéficiaires de la prestation.

Mais chaque étape de production d’un nouveau document à partir du précédent, et son envoi à une nouvelle équipe de personnes, augmente le risque d’erreurs et de malentendus, dans un véritable jeu de téléphone arabe administratif. Généralement, ces erreurs et malentendus sont constamment résolus par de longs appels téléphoniques entre les différentes équipes de votre agence au sujet des documents qu’ils viennent d’envoyer. Ces appels téléphoniques conduisent à beaucoup de prises de décision qui ne laissent souvent aucune trace écrite. Accumulée au fil du temps, cette méthodologie de travail conduit à des spécifications dont les règles ne peuvent pas être retracées à une base légale dans la loi et le décret, et qui risquent de diverger ou même de contredire les instructions du département juridique de votre propre agence. Cela nuit à l’efficacité interne et rend impossible la satisfaction du cadre juridique pour la prise de décision automatisée qui impose des normes de transparence strictes.

Plus globalement, la complexité des processus requis pour traduire les exigences légales en code exécutable pour la prise de décision automatisée est la cible du mouvement “Rules as Code” promu par l’ OCDE. Le but ultime de “Rules as Code” est de réduire toutes les étapes du processus décrit ci-dessus et de publier directement la loi et les décrets sous forme de code exécutable. Bien que l’on puisse penser que Catala permet directement cet objectif ultime, l’équipe Catala ne pense pas que ce soit souhaitable, étant donné les impacts considérables que cela aurait sur l’État de Droit.

Au lieu de cela, l’équipe Catala recommande d’utiliser Catala pour fusionner les deux dernières étapes du processus et fusionner dans le fichier de code source Catala à la fois le code exécutable, et tous les textes qui fournissent la base légale pour votre agence. Le reste de cette page expliquera plus concrètement comment y parvenir.

Pourquoi vous devriez choisir les textes juridiques pour la programmation littéraire en Catala

Comme expliqué ci-dessus, généralement les programmeurs ne se réfèrent qu’aux spécifications lorsqu’ils écrivent leur code, et non aux textes juridiques dont les spécifications ont été dérivées. Par conséquent, il serait logique à première vue d’utiliser simplement les spécifications comme point de départ de la programmation littéraire. Bien que ce soit techniquement possible, l’équipe Catala ne le recommanderait pas car cela empêche l’effort de réécriture vers Catala de reconstruire la chaîne de justifications des micro-choix du texte juridique au code exécutable.

En effet, tout l’intérêt de la programmation littéraire est de fusionner dans un seul document à la fois le code et l’explication de pourquoi le code fonctionne de cette façon. Appliqué à Catala, la programmation littéraire signifie que l’explication de pourquoi le code fonctionne de cette façon doit contenir la base légale de son comportement, donc les textes juridiques.

De plus, utiliser les textes juridiques dans la programmation littéraire au lieu des spécifications accélère considérablement la maintenance du code. En effet, chaque fois qu’il y a une mise à jour dans les textes juridiques, il suffit de propager la mise à jour à la copie du texte juridique dans le fichier Catala (un processus qui peut être automatisatisé), et ensuite de mettre à jour (manuellement) les extraits de code qui se trouvent juste en dessous des textes juridiques mis à jour. La connaissance de quel morceau de code correspond à quelle partie du texte juridique est explicite, ce qui le rend plus robuste au changement de personnel ou à la perte de mémoire institutionnelle. Comparez cela avec le processus traditionnel de mise à jour de la spécification, puis de mise à jour du code : le rédacteur de la spécification et le rédacteur du code (généralement deux personnes différentes) doivent se rappeler quelle partie du document qu’ils écrivent correspond aux parties mises à jour du document qu’ils reçoivent.

Globalement, utiliser les textes juridiques pour la programmation littéraire Catala assure la cohérence de la documentation pour les choix interprétatifs, ainsi que la robustesse et l’efficacité des futures mises à jour du code.

champ d'application RevenuBrutVersNetIndividuel:
  # Une lecture littérale de l'article 364 impliquerait de mettre 10 000 € ici. Mais
  # en fait, l'instruction de l'agence N°1045-58 publiée le 28/04/2023 précise
  # que le plafond est estimé au niveau du foyer et non au niveau individuel.
  # Pour concilier avec la vue individuelle de l'article 364, le plafond ici devrait
  # être un prorata du plafond du foyer par rapport au revenu de chaque
  # individu. Nous supposons que ce prorata est fourni comme variable d'entrée
  # "plafond_deduction_prorata" du champ d'application "RevenuBrutVersNetIndividuel".
  définition deduction_revenu état plafonnement égal à
    plafond_deduction_prorata

# Maintenant nous devons calculer "plafond_deduction_prorata" du champ d'application
# "RevenuBrutVersNetIndividuel", au niveau du foyer. Mais en fait, un mémo interne
# envoyé par le département juridique au département informatique le 05/09/2023 précise
# en outre que le plafond au niveau du foyer ne devrait être proratisé que si la somme
# des revenus des individus dans le foyer est supérieure au plafond.
# Sinon, chaque individu devrait voir comme son plafond individuel le plafond de
# tout le foyer. C'est équivalent car si la somme des revenus est inférieure au
# plafond, alors l'opération de plafonnement n'aura aucun effet.
champ d'application RevenuBrutVersNetFoyer:
  # ...

Recruter une équipe mêlant programmation et connaissances du domaine

Pour cette raison, l’équipe Catala conseille d’avoir un mélange équilibré entre des personnes qui peuvent écrire du bon code (généralement des ingénieurs logiciels) et des personnes qui peuvent comprendre ce que la loi signifie et l’interpréter (généralement des juristes mais pas toujours, comme nous le verrons) au sein de votre équipe pluridisciplinaire. Ce mélange égal implique que vous pouvez organiser l’équipe en paires de personnes : un juriste et un programmeur. Vous pouvez augmenter l’effort de développement en augmentant le nombre de paires dans votre équipe qui peuvent être affectées à des parties indépendantes du calcul.

Nous verrons ci-dessous comment les programmeurs et les juristes passent leur temps au cours d’une semaine typique. Mais d’abord, parlons de quel type de “juristes” nous parlons dans nos équipes pluridisciplinaires. Le mot “juristes” fait généralement référence aux avocats, c’est-à-dire aux personnes défendant des individus et des entreprises devant les tribunaux lors d’un procès. Mais les agences administratives emploient très peu de ce type de juristes, et ces personnes ne sont dévouées qu’à la gestion des procès dans lesquels l’agence est impliquée. Au lieu de cela, les agences administratives emploient généralement un bon nombre de personnes formellement formées en Droit à l’université dans leur département juridique central, chargées d’identifier et de surveiller tous les textes juridiques auxquels l’ agence doit se conformer. Ces “juristes” rédigent ensuite généralement les instructions officielles de l’agence qui paraphrasent le texte juridique, tout en prenant en compte les décisions de justice passées et la doctrine officielle de l’agence. Cela correspond à l’étape 3. du processus en V décrit plus haut dans cette page.

Ensuite, l’étape 4. du processus implique encore d’autres interprétations de la loi. Mais cette fois, c’est souvent fait par des personnes qui n’ont pas de formation universitaire formelle en droit, et qui ne s’appellent pas “juristes”. Cependant, ces personnes ont une connaissance étendue et spécialisée du contenu juridique en question, basée sur des décennies d’expérience antérieure dans leurs postes, ou en tant que travailleurs sociaux de terrain au sein de l’agence. Parfois, ces personnes n’ont jamais vu les textes juridiques pour la prestation ou l’impôt dans lequel elles sont spécialisées, elles n’ont jamais lu que les instructions officielles de l’agence rédigées par le département juridique interne. L’équipe Catala appelle ces personnes les “experts du domaine”, et ils sont aussi cruciaux que les “juristes” pour s’assurer que la chaîne entre la base légale et le code exécutable est pleinement justifiée dans un fichier de code source Catala.

Par conséquent, l’équipe Catala recommande d’inclure un mélange d’“experts du domaine” et de “juristes” de type département juridique au sein de votre équipe aux côtés des ingénieurs logiciels. C’est la combinaison du point de vue de la théorie juridique avec l’expérience de la pratique de cette loi dans l’agence qui est la clé pour atteindre la cohérence du logiciel écrit en Catala avec à la fois les systèmes existants qu’il est censé remplacer et la doctrine juridique officielle de l’agence à laquelle il est censé se conformer.

Emploi du temps hebdomadaire : sessions de programmation en binôme et devoirs

Une fois que vous avez assemblé votre équipe selon les principes énoncés ci-dessus, vous devrez définir des tâches pour chacune de vos paires juriste-programmeur. Pour chaque morceau de travail (que ce soit l’implémentation d’une certaine section d’un statut ou d’un certain champ d’application prédéterminé comme important dans le calcul), le travail doit suivre une boucle itérative composée des étapes suivantes :

1. Identifier les sources juridiques et les instructions et mémos de l’agence justifiant le morceau de calcul ;
2. Les copier-coller dans un fichier de code source Catala et échafauder la structure de données et les déclarations de champ d’application ;
3. Travailler linéairement à travers les sources juridiques, en s’assurant de mettre le code Catala aussi près que possible de la source juridique qui le justifie ;
4. Pendant le travail d’implémentation, des tâches de refactorisation de code et des questions de recherche juridique surviendront inévitablement ;
5. Les traiter en itérant vers les étapes précédentes de cette boucle ;
6. Vous avez terminé quand plus aucune nouvelle tâche de refactorisation ou question de recherche juridique ne survient !

En suivant les boucles précédentes, le programmeur et le juriste de la paire seront occupés à temps plein pendant une semaine typique. L’organisation de la semaine pour les deux devrait être centrée autour d’une session hebdomadaire de programmation en binôme de 2 à 3 heures, avec le schéma suivant :

• avant la session de programmation en binôme, le juriste doit envoyer au programmeur les listes de textes juridiques à prendre en compte pour le morceau de travail actuel ;
• sur cette base, le programmeur doit écrire un échafaudage initial de structure de données et de déclarations de champ d’application à utiliser pendant la session de programmation en binôme ;
• le juriste doit également rechercher préventivement les décisions de justice pertinentes et les documents de doctrine de l’agence avant la session de programmation en binôme ;
• un ordre du jour est communément fixé par le juriste et le programmeur pour la session de programmation en binôme à venir, priorisant les tâches à accomplir ;
• pendant la session de programmation en binôme, le juriste et le programmeur doivent discuter du texte de loi et essayer d’esquisser ou d’implémenter entièrement des extraits de code Catala (généralement des définitions de variables de champ d’application) ;
• ils doivent également noter dûment toute tâche de refactorisation ou question de recherche juridique qui survient pendant la session comme tâches à faire ;
• ces tâches à faire doivent occuper à la fois le juriste et le programmeur après la session de programmation en binôme et avant la suivante ;
• de plus, le juriste doit préparer de manière asynchrone des cas de test que le programmeur (ou le juriste) peut implémenter et ajouter à la base de tests pour l’intégration continue ;
• une fois terminé, le morceau de travail est matérialisé sous forme de proposition de fusion (merge request) complète avec implémentation et tests, à examiner à la fois juridiquement et informatiquement par une autre paire juriste-programmeur.

Si tout cela ne remplit pas la semaine de travail, le programmeur peut travailler en plus sur des tâches de programmation liées au déploiement du projet tandis que le juriste peut travailler à la rédaction de mémos internes documentant l’avancement du projet et comment les décisions qu’ils ont prises en programmant sont conformes à la doctrine de l’ agence.

Suivi des progrès et planification du travail

Globalement, vous savez que vous réimplémenterez un certain calcul d’impôt ou de prestation, mais comment diviser le travail en tâches et les distribuer aux paires ?

Pour la gestion de projet au jour le jour, l’équipe Catala vous conseille de faire plein usage des plateformes de génie logiciel comme Github, Gitlab ou Jira. Non seulement les tâches de codage peuvent être modélisées et suivies comme des tickets et des pull requests sur ces plateformes, mais les tâches juridiques peuvent également être modélisées et suivies comme des tickets. En particulier, l’équipe Catala a noté qu’il est très utile de mettre toutes les tâches à faire collectées à la fin d’une session de programmation en binôme sous la forme de tickets dans la plateforme. Ensuite, l’avancement du projet peut être suivi avec des tableaux de tickets, des listes et une estimation du temps comme un projet logiciel standard.

Vous pouvez également utiliser des étiquettes de tickets pour marquer les questions juridiques qui ont été recherchées ou validées par le département juridique de l’agence. Étiqueter les tickets facilite la planification de l’ordre du jour de la prochaine session de programmation en binôme et le tri entre les tâches qui nécessitent encore des recherches ou une validation supplémentaires, et celles qui peuvent être implémentées en code Catala tout de suite.