Réaliser un modèle complexe

Le modèle de simulation routière décrit durant les trois derniers articles était un modèle particulièrement délicat à concevoir. Pour simplifier, on peut dire qu’il y a deux façons de développer un modèle complexe : top-down et bottom-up.

L’approche top-down est l’approche traditionnelle, celle qui est utilisée dans les cours de programmation habituels et dans la plupart des sociétés de conseil. On décompose la tâche en sous-tâches, par exemple avec un organigramme, puis en sous-sous-tâches, et on les donne à développer à des programmeurs.

L’inconvénient est que cela fait souvent intervenir au moins trois personnes : un analyste astucieux pour analyser le travail à faire, un chef-programmeur pour découper tout cela en étapes, et un développeur (ou plusieurs) pour écrire le code. Le problème alors est que, si l’on se trompe quelque part, on risque de ne le constater qu’à la fin, ce qui coûte très cher ! Autre inconvénient, on ne peut pas montrer au client ce que cela donnera tant que ce n’est pas fini. On se prive donc d’une interaction efficace avec lui.

L’approche bottom-up est celle que j’utilise depuis plus de 50 ans. Je programme au début le noyau du code à réaliser, en simplifiant le cahier des charges. Quand cela fonctionne bien, je rajoute des fonctionnalités, puis d’autres fonctionnalités encore…

L’avantage est qu’avec un seul intervenant (je fais l’analyse, la programmation et la mise en place), on va bien plus vite, et que l’on ne récupère pas des erreurs liées à des problèmes de communication entre les intervenants. L’inconvénient est que, si la personne qui fait tout cela n’est pas astucieuse et n’a pas une vision globale des possibles extensions, elle construit une « usine à gaz ».

C’est pour cela que cette approche n’est pas pratiquée autant qu’elle pourrait l’être. Ce qui est amusant, c’est que la mode aujourd’hui est de parler de méthodes agiles qui, de fait, reviennent grosso modo à cela. Et c’est cette approche que j’ai pratiquée durant la totalité de ma carrière… Ce qui m’a permis de faire des réalisations toujours entre 3 fois et 10 fois plus rapides (en temps de développement) et 3 et 10 fois moins chères que celles de tous mes concurrents.

L’approche utilisée pour ce modèle

Comment donc ai-je fait pour développer ce modèle en mode bottom-up ?

J’ai commencé par élaborer un modèle simple pour simuler le trafic, en prenant les fichiers ne contenant que des jours de semaine normaux.

Quand les estimations de trafic de mon modèle ont fini par bien coller avec les observations sur ces fichiers, je me suis mis à analyser des fichiers de début de semaine et de fin de semaine. J’ai alors ajouté de nouvelles règles et modifié mes formules pour que, pour ces jours particuliers, le modèle donne aussi de bons résultats.

Enfin, j’ai analysé les fichiers des jours fériés, de départ en vacances et de retour de vacances, jusqu’à ce que eux aussi donnent avec mon modèle des résultats réalistes.

Validtion et amortissement du modèle

Comment AdP (Aéroports de Paris) a-t-il procédé pour valider ce modèle ?

Nous avons convenu ensemble qu’AdP ne me transmettrait que la moitié des fichiers Excel. Ils gardaient ainsi 50% des fichiers de jours normaux, de week-ends, de départs en vacances, de retour de vacances,…

Ils ont utilisé ces fichiers, que je ne connaissais pas, pour vérifier les prédictions de mon modèle, et voir si l’écart entre mes prédictions et la réalité observée était raisonnable ou non. Ils ont ainsi confirmé la validité de mon modèle.

Ce modèle a coûté à AdP plus de 60 K€. Le modèle a été amorti en moins de 6 mois. Il était envisagé en effet de modifier une intersection, en remplaçant un rond-point par un feu rouge. Le modèle a prouvé que,si l’on faisait cela, on aurait certes résolu le problème immédiat de ralentissement du trafic au rond-point, mais que le problème aurait alors été reporté que de quelques centaines de mètres, dans la création d’un nouvel embouteillage…