L’informatique n’est pas la solution

Divulgâchage : Un peut comme un point godwin, il arrive toujours qu’on se dise “et si on informatisait tout ça”… Ça n’en vaut souvent pas la peine.

Lorsque j’étais enfant, je me rappelle l’ennui abyssal des compétitions de Judo. Nous partions tôt le matin pour être à l’heure pour la pesée qui pouvait durer une heure puis attendions une heure supplémentaire pour que les organisateurs nous répartissent en poules et affichent enfin le planning approximatif de la journée. Passer tôt ou tard n’avait aucune espèce d’importance puisque la remise de médaille se ferait à la toute fin. Dans mes souvenirs, une compétition de judo, c’était une journée d’ennui à attendre dans le bruit.

Puis, certains clubs ont décidé de remettre les médailles au fil de l’eau ; chaque poule allait sur le podium dès ses combats terminés et les parents pouvaient alors rentrer chez eux. En cette toute fin de XXème siècle, je ne vous raconte pas l’innovation que ça représentait et les remous que ça a généré. Les parents ont adoré le concept, la buvette un peu moins (mais on était de toutes façon trop pauvres pour y acheter quoi que ce soit). Il fallait toujours aller à la pesée du matin mais on n’était plus obligés de rester jusqu’à pas d’heure.

Quelle ne fut pas ma surprise lorsque mes enfants ont participé à leur première compétition ; que de changements en 20 ans… La pesée est faite par le professeur lors d’un entraînement la semaine précédent la compétition et les horaires sont annoncés un mois à l’avance. Il suffit d’arriver à l’heure prévue, de donner son nom à l’entrée, participer à l’échauffement commun puis les poules démarrent et les médailles sont données dès qu’une poule termine. En moyenne, il faut une heure pour que tous les enfants d’une catégorie d’âge soient passés.

Vous vous rendez-compte ? On a divisé le temps d’ennui par 10 en vingt ans !

Mais parfois, la compétition a des ratés. L’inscription est laborieuse et une longue file d’attente se crée à l’entrée du dojo. Ou bien les poules sont déséquilibrées ; au lieu de poules de 4 judokas (6 combats), on a des poules de 6 (quinze combats). Chaque catégorie peut alors prendre du retard qui peut se cumuler et les parents malchanceux doivent rester une heure et demi au lieu d’une heure.

Personnellement, je trouve qu’une heure et demi contre la journée complète, souvenir de mon enfance, c’est déjà très bien. Mais la plupart des parents n’ont pas, ou plus, ces références et comparent avec les autres compétitions où ils n’ont du rester qu’une heure max. Bref, c’est un peu la honte pour l’organisateur.

Pour que ça ne nous arrive pas lors de la compétition qu’on va organiser, un des parents a suggéré l’idée de bon sens que tout le monde s’était faite la dernière fois qu’une compétition a « dérapé » :

On doit informatiser tout ça : un CTRL+F dans un tableur et c’est parti !

L’idée évidente

C’est si évident… Lorsqu’un enfant arrive, il dit son nom, on fait une recherche dans le tableau, on met une case à 1 et on imprime les feuilles de poules. Il y a sûrement une petite popote à faire entre les deux pour répartir les enfants dans les poules mais ça doit être simple ?

Et j’ai répondu « non ».

Version informatique

Le gros problème lorsqu’on veut « informatiser tout ça », c’est qu’on ne voit que le sommet de l’iceberg et qu’on oublie toutes ces choses qui entrent dans « tout ça », et toutes les autres qui sont nécessaires pour « informatiser ».

Tout ça

Puisqu’on est une petite compétition, on va rester modeste et viser le Minimum Viable Product : on va gérer uniquement les inscriptions et la répartition des enfants dans les poules. C’est tout. Même si ça nous démange, on ne va pas informatiser le chronomètre, les scores, l’ordre des combats, l’affectation des poules aux tables, les classements et le reste.

On va donc avoir besoin d’une base de donnée pour stocker les données. Pour chaque participant, nous avons besoin de son nom, prénom, sexe, année de naissance, poids et club. Nous lui affecterons un numéro de poule ça sera suffisant et ça permet de n’utiliser qu’une seule table pour l’ensemble des données. Il y aura peut être de nouvelles colonnes à ajouter mais on verra ça au fur et à mesure.

Mais du coup, vous déteniez des données personnelles (nom et prénom). Vous prenez conscience d’être responsable des données et devoir fournir un droit d’accès, de rectification et de suppression des données. Et comme nous avons l’année de naissance et le poids, nous avons des données de santé et une obligation de sécurité renforcée de toutes ces données. Et oui…

Si vous voulez partir sur une application web pour gérer les inscriptions par les professeurs, il faudra ajouter une gestion des utilisateurs pour qu’ils puissent lister leurs inscriptions, modifier leurs erreurs et désinscrire des enfants. Du coup il faut aussi ajouter des droits d’accès. Et aussi pouvoir désactiver ce site avant le début de la compétition sinon ça va être le bordel.

Dans tous les cas, il faut que les organisateurs sur place puissent pointer les présents (le fameux « CTRL+F ») mais aussi ajouter les retardataires et corriger les coquilles dans tous les champs car il y aura des erreurs lors des inscriptions (croyez-en mon expérience).

Concernant la recherche, comme il n’est pas toujours évident de savoir comment un nom ou un prénom s’écrit, cette fonction devrait idéalement rechercher aussi des correspondances approchées. Ce serait une grosse perte de temps si on devait demander à chaque enfant d’épeler son nom et son prénom. Prévoir aussi une fonction « annuler » parce que dans le feu de l’action, on s’est peut être trompé de judoka.

Il faut ensuite qu’un bouton permette de répartir les enfants en poules puis imprime les feuilles de poules. C’est ici que ça devient franchement amusant parce qu’on ne fait pas des poules n’importe comment. Voici les critères à prendre en compte :

Il faut ensuite pouvoir encoder toutes sortes de contraintes arbitraires et improvisées. Comme ces deux cousines dont les familles ne se supportent pas et il vaudrait mieux éviter qu’elles se croisent dans les gradins. Elles ont le même âge et le même poids. Pas de bol elles sont les deux plus légères de leur catégorie. L’une peut aller avec les trois autres plus légères mais ensuite la différence est trop grande… On peut mettre l’autre avec des garçons du même âge (elle est combative, ça pourrait lui aller) ou avec les filles plus jeunes qui ont son poids (et comme c’est un autre horaire les familles ne se croiseront pas)…

J’ai fait quelques prototypes en programmation logique par contraintes (en Answer Set Programming si vous voulez tout savoir) et je n’ai jamais réussi à obtenir une solution satisfaisante. Soit j’ai quelques rares poules qui clochent parce qu’une contrainte importante n’est pas respectée. Soit j’autorise des exceptions mais le système en abuse et me génère trop de poules exceptionnelles (et pas toujours heureuses non plus). Il est peut être possible, avec du temps, d’obtenir un programme satisfaisant, mais mon intuition est que les contraintes ne sont pas comparables entre elles et ne peuvent être combinées pour produire un score à minimiser.

Mais soyons optimistes et imaginons que ces contraintes ne sont pas un problème. Admettons aussi qu’il sera facile d’interfacer le tableur avec un système logique par contrainte (ou pour les plus optimistes, de coder un équivalent dans leur langage préféré).

Est-ce que vous acceptez les retardataires ? Ça arrive tout le temps pour tout un tas de raison et c’est dommage de dire à un enfant motivé qui a fait des kilomètres pour venir qu’il doit rentrer parce qu’il est en retard (alors que des poules de sa catégorie n’ont pas encore commencé). Le programme devra donc connaître l’état des poules (en attente, en cours, terminé) pour pouvoir ajouter un retardataire. De préférence dans une poule en attente, sinon une en cours (mais il faut savoir où elle combat). Et arbitrer la priorité de cette nouvelle contrainte et des anciennes…

Et jusqu’ici, nous n’avons fait qu’effleurer la surface. En implémentant un premier prototype, vous vous rendrez compte qu’il y a beaucoup de détails à préciser. Par exemple, l’authentification utilise un pseudonyme ou une adresse de courriel ? autorisez-vous un formulaire de récupération de mot de passe ? Comment fonctionne vraiment la fonction de recherche pour valider l’inscription d’un judoka ? Quelles sont les priorités relatives des critères pour les poules ? Et je ne parles même pas des retours des utilisateurs lorsqu’il testerons votre version 1…

Informatiser

Même si c’est pour une petite compétition, on veut éviter de déraper sur l’inscription et la génération des poules pour ne pas avoir la honte devant les parents et les autres clubs. On espère qu’en informatisant on gagne du temps, on acceptera si on en gagne pas vraiment mais on ne supportera pas d’en perdre.

L’enjeu est bien pire que des indemnités, c’est d’honneur dont il est question. Contrairement à une entreprise de développement informatique qui fera stipuler sur le contrat une « obligation de moyens » et pourra souscrire une assurance pour couvrir les dommages « à hauteur du prix de la licence ». En tant que bénévoles nous avons une obligation tacite de résultat.

Côté performance. Je dois maintenant vous avouer que ce qui prendra le plus de temps lorsqu’on aura informatisé tout ça, c’est de prendre l’identité des enfants. Lorsqu’il arrive à la table et qu’on leur demande comment il s’appelle, entre le bruit ambiant et sa diction mal assurée, il faut parfois s’y reprendre à plusieurs fois pour avoir une idée approximative de l’orthographe du nom et du prénom. Et c’est ça qui génère les files d’attentes qu’on veut éviter.

On va donc devoir paralléliser cette étape et que plusieurs personnes s’en charge. Chacune munie d’un ordinateur (ou d’une tablette ou autre) contenant notre application. Et pour que ces applications se synchronisent le plus simple est de répartir l’application sur un serveur central et des clients. Dans tous les cas il faudra mettre en place un réseau informatique.

Côté efficacité. Il est inconcevable que le système souffre de la moindre défaillance ; que ce soit un bogue ou une panne. Car si ça arrive, on va perdre un temps fou et peut être devoir reprendre le travail à la main.

Pour éviter les bogues logiciels, il va falloir développer comme des pros. Avec des batteries de tests unitaires, des tests d’intégration et des recettes avec les bénévoles pour vérifier que l’outil fonctionne sur leur matériel (et qu’ils arrivent à s’en servir) et avec le professeur pour vérifier que les poules respectent ses critères (donc prévoir aussi des données de tests représentatives… tout un programme).

Pour éviter les bogues réseau, il faut un administrateur réseau sur place qui installe et vérifie le matériel avant le début de la compétition puis soit disponible pour corriger rapidement toute erreur à cause d’un matériel qui aurait perdu sa configuration. Je considère que tous les équipements sont sur place pour éviter de dépendre du réseau Internet.

Pour éviter les pannes, il faut du matériel redondant. Que ce soit les ordinateurs utilisés par les personnes, les imprimantes mais aussi le serveur qui doit pouvoir supporter une panne (i.e. un disque dur qui casse ou une surtension sur une barette de RAM). En cas de panne, il faut pouvoir remonter le système en moins de 3 minutes. J’irais presque jusqu’à mettre deux serveur en maître/esclave pour pouvoir basculer de l’un à l’autre (mais ça impose de le concevoir et de le tester…).

Restes les pannes électriques. Ce serait pas de bol mais ça peut arriver… Prévoir un groupe électrogène ?

Plan B. Et comme vous n’allez sûrement pas pouvoir tout tester, vérifier et redonder : vous prévoirez le nécessaire pour pouvoir le faire à la main si l’informatique est en rade.

Version à l’ancienne

Pour bien se rendre compte à quel point la solution précédente est inadaptée au contexte, comparons avec la méthode plus classique que j’ai utilisée jusqu’ici…

Avant la compétition, les professeurs m’envoient un courriel avec la liste des judokas. Ils peuvent l’envoyer à mon professeur qui me le fait suivre. Je centralise toutes ces données dans un unique tableau. Un ou deux jours avant la compétition, je prépare les poules comme suit :

Une fois qu’on a pris le coup de main, ça se fait bien et sans prendre trop de temps. C’est comme résoudre un puzzle donc c’est même agréable à faire quand on aime ce genre de chose. L’avantage, c’est que si on découvre une nouvelle contrainte, on peut l’appliquer directement sans se demander comment modifier le programme pour qu’il s’en sorte sans tout casser ce qui marchait déjà.

Pour le jour de la compétition, j’imprime la liste des participants triés par ordre alphabétique avec pour chacun leur numéro de poule (en plusieurs exemplaires). J’imprime aussi les poules prévues et numérotées (mais dans des feuilles prévues pour 6 combattants, vous allez comprendre pourquoi ensuite). J’imprime aussi quelques feuilles de poules vierges.

Le jour de la compétition, on a deux groupes. Ceux qui accueillent les enfants relèvent leur identité, recherche dans la liste. S’il trouvent, ils passent la ligne au fluo (ça facilite la recherche ensuite puisqu’on voit les lignes qu’on a plus besoin de lire) et disent au deuxième groupe le numéro de la poule et l’identité. Le deuxième groupe s’est réparti les poules par intervalles, lorsqu’ils entendent un numéro dans leur intervalle ils y trouvent le judoka et le passe au fluo. Une fois une poule complète, elle peut être empilée à part. Si un judoka n’est pas inscrit, il passe à une table à côté pour le peser et l’inscrire sur une nouvelle liste.

Cette méthode n’est pas plus lente qu’un « CTRL+F ». Elle serait même plus rapide car on va plus vite à passer une ligne au fluo qu’à manipuler le clavier pour lancer la recherche puis écrire un nom (le tout plusieurs fois car avec le bruit on a pas bien compris comment le nom s’écrivait) puis valider l’inscription.

Une fois tous les judokas passés, pendant qu’ils s’échauffent, on a largement le temps de terminer les poules. On barre sur les feuilles de poules les noms des absents (ceux qui ne sont pas passé au fluo). Les nouveaux inscrits peuvent être insérés dans une poule d’un poids compatible (elles sont triées par poids) en inscrivant leur nom à la main dans une des cases vides. Avec les absents, on peut avoir des poules de 1 ou 2 qu’on réparti en les inscrivant sur les poules voisines. Et si nécessaire, je dispose de feuilles vierges pour créer des poules ou réécrire celles qui seraient devenues illisibles.

Comparée à une version informatisée, on voit bien qu’on est aussi rapide mais on nécessite moins de matériel, on a moins de risques de bogues, aucun risque de panne et ça permet d’improviser sur l’instant (ce que l’informatique ne permet pas).

Et après ?

Cet exemple concerne l’organisation d’une compétition de judo pour enfant mais c’était un prétexte parce que le principe est bien plus général. Que ce soit dans des expertises civiles ou dans la vie normale, je rencontre bien trop souvent des applications qui ont été développées avec de (très) gros budgets et accouchent d’usine à gaz qui échouent à résoudre le problème qui les a vus naître.

À chaque fois, le client a rêvé que l’informatique lui facilite la vie et a trouvé un prestataire pour l’accompagner dans son délire. Il aurait été bien plus économique, écologique et même ergonomique de mettre en place une solution « low tech » mais ça n’est pas dans l’intérêt du prestataire à court termes. D’abord parce que ça rapporte plus ; on peut facturer plus de gestion de projet, plus de R&D et plus de maintenance. Ensuite on reste sur une obligation de moyens ; puisque c’est le client qui décide, c’est lui qui prend la responsabilité et c’est toujours bon à prendre. Et surtout, le client n’aime pas être contredit ; il sait déjà ce qu’il veut et trouvera un autre prestataire si besoin.

Mais il serait malhonnête de rejeter la faute sur l’ignorance des clients et la cupidité des entreprises car la racine est aussi culturelle chez les informaticiens. Les filières d’enseignement passent leur temps à demander aux élèves de modéliser des situations « tirées de la vie réelle » pour informatiser tout ça. Après plusieurs années d’études, c’est devenu un réflexe : toute situation de la vie courante devient une occasion de démontrer sa virtuosité en modélisation, algorithmique et programmation. On nous a donné un marteau, nous voyons des clous partout. Le problème, c’est que là où les situations pédagogiques avaient été choisies et calibrées pour être informatisables, les situations vraiment réelles sont bien plus complexes ce qui introduit un coût caché qu’il faut bien payer un jour. C’est dommage car la plupart du temps, il suffit d’un pas de côté pour trouver une solution plus simple.

Je rêve d’un module d’enseignement intitulé « de l’art de se passer d’informatique » (qu’on pourrai aussi appeler « Keep It Stupid Simple ») où les étudiants seraient confrontés à des problèmes classiques de modélisations informatiques mais seraient incités à produire les solutions les plus simples. Quand on leur dira que des maîtresses d’école ont besoin de communiquer avec des parents, ils échouerons à l’épreuve en modélisant un ENT mais réussirons en proposant une simple liste de diffusion. Points bonus pour ceux qui se rappelleront qu’un cahier de liaison existe déjà et permet, contrairement à l’informatique, de responsabiliser les enfants.