Fr V-2.012r5 : une release avec trop de bugs ?
(La décision a été prise d'opérer un test complet de la version 2.012r5 du pays des 450 fromages après une succession de dysfonctionnements rapportés par ses utilisateurs. Il semble que de nombreux bugs (ou assimilés) soient présents et que le passage en V-2.012r6 soit nécessaire pour éviter un plantage général qui pourrait avoir comme conséquences une saturation mémoire impliquant alors une paralysie du système qui mettrait une grande majorité des utilisateurs en difficulté.
(La décision a été prise d'opérer un test complet de la version 2.012r5 du pays des 450 fromages après une succession de dysfonctionnements rapportés par ses utilisateurs. Il semble que de nombreux bugs (ou assimilés) soient présents et que le passage en V-2.012r6 soit nécessaire pour éviter un plantage général qui pourrait avoir comme conséquences une saturation mémoire impliquant alors une paralysie du système qui mettrait une grande majorité des utilisateurs en difficulté.)
La version 2012 du logiciel France, release 5 (5ème république) a de nombreux défauts mais aussi des qualités. Premiers points importants à prendre en compte : c'est une version patchée depuis 1958 à de nombreuses reprises et plus particulièrement depuis 2007. De nombreuses modifications du logiciel ont donc été apportées ainsi qu'une console d'administration totalement remaniée. Pour autant le cœur du logiciel Fr n'a pas été touché depuis sa nouvelle programmation en langage CDG(datant de 1958, du nom du concepteur du langage qui a permis la programmation du logiciel r5, ndlr), réputé pour sa simplicité d'accès, sa robustesse, mais très rigide et ne supportant pas une trop grande complexité algorithmique ni une trop grande interaction avec des logiciels tiers, ce qui est pourtant le cas aujourd'hui.
Nous allons donc tenter de savoir ce qui pourrait créer les dysfonctionnement rapportés par des millions d'utilisateurs qui ne supportent plus de se voir "plantés" en pleine saisie de données, ou encore mis en attente par la console d'administration qui leur explique que des modifications vont être mises en œuvre, sans parler des divers bugs incompréhensibles qui surviennent en permanence générant angoisse, énervement et autres agacements qui dans les rapports d'audit, indiquent que certains utilisateurs se disent, par exemple, prêts à "foutre en l'air ce putain de logiciel qui commence à sévèrement les briser". Cet extrait, trivial, reflète assez bien l'ambiance générale face au logiciel Fr V-2.012r5, et c'est pourquoi il nous a semblé important d'effectuer en deux étapes, un audit, basé sur l'injection de jeux de données test, suivi de tests utilisateurs. Comme vous le verrez, il semble que de nombreux bugs n'en sont pas véritablement. La programmation en CDG a ses limites, certains algorithmes rentrent en conflit avec d'autres ou donnent des résultats inattendus, bref, nous avons été surpris par les constats de ces tests.
Insertions de jeux de données
Le CDG est un langage séquentiel, comme tous les langages de cette époque. Plus facile à débuguer que ses concurrents orientés objet, il n'en reste pas moins limité et lourd à mettre en œuvre. Plutôt rapide si les procédures à effectuer sont simples, d'une lenteur affligeante si l'on commence à vouloir l'adapter à des procédures complexes et de nombreux utilisateurs connectés simultanément et cherchant à utiliser des fonctions différentes. Ces quelques indications données, passons à un premier jeu de test basé sur des retours utilisateurs inquiétants mais néanmoins réels et concrets.
Premier test : insertion d'un jeu de données de type "fait divers" dans fr-V2.012r5
Lorsque nous avons inséré ce jeu de données, déjà testé de nombreuses fois depuis la programmation en CDG du logiciel Fr dans ses différentes versions r5, nous avons eu la surprise de constater les effets suivants : ralentissement complet de toutes les autres fonctions, affichage quasi permanent de la console d'administration (au point d'empêcher les utilisateurs de continuer à saisir correctement leurs données), messages d'information permanents et souvent contradictoires, déclenchement d'alertes et de demande de patchs correctifs de la part des administrateurs. Il semble que des algorithmes rentrent en conflit lorsque un jeu de données de type "fait divers" est inséré : ces algorithmes qui tournent en tâche de fond dans la console d'administration, opèrent des séquences aléatoire qui déclenchent d'autres algorithmes dans la console de messages d'information utilisateurs. Ces allers-retours saturent la mémoire du logiciel et causent les ralentissements constatés ainsi que les messages parasites. La gestion des données ayant pour valeur "fait divers" n'est pas correctement traitée par fr-V2.012r5. Le bug est important et doit être absolument corrigé dans une version ultérieure.
Deuxième test : insertion d'un jeu de données de type "valeur financière en euro" dans la console de gestion financière de fr-V2.012r5
Très étrange, mais les rapports utilisateurs nous avaient alertés, lorsqu'un jeu de données de valeurs financières en euro est inséré, le logiciel opère un nombre croissant d'opérations qui ne sont pas prévues à l'origine par le logiciel. Il semble que ce soient des fonctions insérées assez récemment, des "patchs". L'étrangeté de ces patchs est qu'ils font exactement l'inverse de ce qui est renvoyé par la console d'administration aux utilisateurs. D'où les alertes utilisateurs. Nous avons donc effectué une injection de données de valeurs 1000 milliards et opéré une simulation sur 5 ans : deux tiers de cette valeurs disparaît du système utilisateurs pour être insérée dans une autre console. Les effets sont assez ennuyeux : les données insérées par les utilisateurs semblent être utilisées à d'autres fins que celles établies par le logiciel à l'origine, au point que le journal de log nous indique que la valeur dette publique a augmenté de 600 milliards en 5 ans, ce que fr-V2.012r5 ne doit normalement pas permettre : des algorithmes assez anciens sont en place pour contrôler l'augmentation des valeurs, et les valeurs de "dette" ne peuvent normalement pas croître à cette vitesse.
En regardant de plus près nous avons en réalité compris ce qu'il se passait : de multiples patchs ont permis de passer outre les algorithmes de contrôle qui ont été eux aussi modifiés, et ces patchs ont permis que les valeurs de retour de la fonction "recette" soit en permanence inférieure aux valeurs de retour de la fonction "dépenses". Toutes ces modifications ont été opérées depuis la console d'administration centrale, et si une partie des modifications a été indiquée aux utilisateurs, d'autres ne l'ont pas été, ou dans des messages longs et complexes qui ne pouvaient pas leur permettre de comprendre correctement la modification.
Troisième test : insertions de différents jeux de données reliés à des logiciels externes partenaires
Les résultats sont sans appel : la release 5 ne passe pas bien du tout ces tests. Les difficultés à échanger des données avec d'autres logiciels est très fastidieuse, la compatibilité entre le CDG et d'autres langages, même avec l'aides des transcripteurs et compilateurs de haut niveau, une armée de programmeurs qui aident à améliorer ces compilations, est souvent aléatoire et crée des blocages du logiciel. Certaines fonctions se valident sans problème, d'autres très mal. Une fonction nommée "UE" par exemple, qui comporte un code modifié en CDG, à l'origine très court et léger est désormais très conséquent (450 millions de ligne de code) et a une compatibilité totalement aléatoire : elle fonctionne via la console d'administration, pas du tout du côté utilisateurs. De la même manière, si l'on entre des données de type "relations internationales", le code génère des résultats très dissemblables, résultats que les utilisateurs ne comprennent pas. Nous avons testé une valeur "Kadhafi" par exemple et simulé une durée de 30 ans. Le résultat se modifie en permanence. Mais de la même manière il semble que le code et les patchs installés dans la console d'administration soient en cause.
Il faut souligner que d'autres fonctions en interaction avec d'autres logiciels ne créent aucun problèmes. C'est le cas des fonctions "banques", "circulation des flux financiers" par exemple. Les données insérées sont tout à fait bien traitées et très bien gérées par les logiciels partenaires extérieurs à CDG. Nous avons voulu comprendre pourquoi, cela n'a pas été possible : cette partie du code n'est pas accessible, mais nous avons la certitude que ce code n'a pas été écrit en CDG mais en GF, un code orienté objet datant du début des années 1990 et implémanté à 100% pour l'écriture du logiciel Usa-V.2.0r3 de 1999. Comment le CDG, langage séquentiel arrive-t-il à communiquer avec un langage orienté objet comme le GF ? Nous ne le savons pas mais pensons qu'en réalité, comme aucun utilisateur n'a accès aux fonctions "banques" et "circulation des flux financiers", ce sont plutôt deux logiciels parallèles qui n'échangent que des données et rien d'autres. Une précision : la console d'administration programmée en CDG semble avoir un accès de type "données" au logiciel tiers Usa-V.2.0r3 écrit en GF. Il est possible que le GF, langage très ardu et complexe interagisse avec le CDG, générant des bugs mais nous n'avons pas pu le vérifier. Il n'en reste pas moins que des données sont échangées entre les logiciels et qu'elles affectent certains résultats.
Tests utilisateurs
Vu l'état d'énervement des utilisateurs, les tests n'ont pas été simples. Nous avons voulu, avant de procéder aux tests, connaître les fonctions, consoles qui posent problèmes aux utilisateurs. Une majorité a mis en cause :
-Les contraintes d'utilisation du logiciel
-Les limitations permanentes et en augmentation croissante des fonctions par les administrateurs et leur console d'administration
La non prise en compte de leurs demandes de modification pour améliorer le logiciel
Des bugs incessants et des données qui disparaissent
Nous ne retranscrirons pas tous les tests effectués, ce rapport serait trop long. Mais quelques exemples semblent intéressants :
Nous demandons aux utilisateurs d'utiliser la fonction "participation à la vie démocratique". Les utilisateurs nous retournent que la fonction a été désactivée par les administrateurs.
Nous demandons aux utilisateurs d'utiliser la fonction "travailler". Une part conséquente des utilisateurs voit s'afficher des messages d'erreur différents par la console d'administration ainsi que des fenêtres de communication et de remontées d'erreurs très aléatoires.
Quelques exemples de ces messages : "fonction indisponible, charge processeur trop importante", "mémoire insuffisante, trop d'accès simultanés", "des processus externes à CDG empêchent le logiciel de vous donner l'accès à la fonction travailler", "désolé, une instance GF est en cours, nous ne pouvons répondre à votre demande".
Oui, le dernier message que de nombreux utilisateurs nous ont remonté nous ont mis sur une piste : fr-V2.012r5 est très certainement codé désormais aussi en GF, et des bugs entre le GF (qui code une bonne partie des logiciels actuels présents sur le marché) et le CDG, au delà d'un simple échange de données semblent certains.
Il semble aussi évident que la console d'administration est trop utilisée et génère de nombreux bugs avec certaines données, plus particulièrement des données utilisateurs. Les instances de communication donnent elles aussi l'impression d'avoir progressé en terme de lignes de code de façon substantielle amnenant une dégradation de ce même code. On trouve aujourd'hui des bouts de programme de communication qui traînent un peu de partout, remontent vers la console, descendent vers les utilisateurs, s'entrecroisent, génèrent de nouveaux codes.
Le logiciel fr-V2.012r5 est un logiciel très lourd, au code obscur, qui comporte visiblement des parties écrites dans d'autres langages tels que le GF, génère des incohérences fréquentes pour les utilisateurs. Les bugs a répétition, surcharge de messages d'information, saturation mémoire indiquent que cette version ne va pas pouvoir longtemps continuer à fonctionner. La demande de changement des administrateurs du logiciel ne nous semble pas une solution suffisante : de nombreuses alertes des consoles ou messages et fonctions (comme la fonction "UE") ont été programmées pour se déclencher sans administrateurs, de façon automatique et nous doutons de la maîtrise des programmes tiers codés en GF qui continuent à alimenter en données fr-V2.012r5.
Il nous semble donc nécessaire de coder une nouvelle version du logiciel fr dans un autre langage que le CDG, qui offre un accès à la console d'administration contrôlé et un ensemble de fonctions utilisateurs plus directes d'accès. Le GF, ne semble pas une bonne piste, puisqu'il est un langage propriétaire très mal documenté et non-exempt de défauts. Un nouveau langage, ouvert et modifiable, participatif semble une bonne voie, afin de coder un logiciel fr-V.2012r6 plus à adapté aux besoins actuels, en amélioration permanente et offrant les meilleurs services possibles aux utilisateurs tout en permettant un échange avec des logiciels tiers.