Réflexions sur la modélisation
Je vais être dans l’impossibilité d’alimenter ce blog durant 15 jours. A titre de compensation, je vous propose aujourd’hui un article sensiblement plus long que mon format habituel d’une à deux pages. Et ce seulement un jour après ma dernière contribution :)
J’ai commencé à développer des modèles pour les entreprises au début 1970, donc il y a plus de 40 ans. Diplômé de l’ENSIMAG, j’étais alors étudiant au MIT, pour un Ph.D. (doctorat) en recherche opérationnelle. J’ai créé ma première société de conseil, Flight Transportation Associates, quand j’étais encore étudiant. Toutes ces années de conseil représentent une certaine expérience :)
En plus de 40 ans, j’ai développé plus de 1.000 modèles, pour plus de 100 entreprises, dans plus de 10 pays. Au début en Fortran et en assembleur, puis sur Visicalc (le premier tableur, en 1979), Multiplan (à partir de 1982) et enfin – depuis 1985 – exclusivement sur Excel.
Ce qui m’a toujours frappé, c’est l’écart phénoménal que l’on peut constater entre des modèles créés par monsieur tout-le-monde et des modèles réellement performants : un modèle efficace est développé bien plus rapidement, se calcule sensiblement plus vite et occupe beaucoup moins de place en mémoire. Un modèle efficace représente donc une situation de win-win-win par rapport à un modèle lambda !
Temps de développement du modèle
Le tableau ci-dessous illustre quelques écarts entre les temps demandés pour un développement en interne et ceux que j’ai proposés en devis forfaitaire (et que j’ai tenus).
Notez l’excellente performance d’EdF : avec son écart représentant seulement un facteur 4, EdF est la société où j’ai trouvé le plus petit écart avec mon propre temps de développement.
Chaque fois que je me suis trouvé en concurrence avec d’autres sociétés de conseil dans le cadre d’un appel d’offres, mon devis a toujours été entre 3 et 10 fois moins cher que celui du second moins-disant (je ne parle même pas des autres).
Quand un modèle est développé plus rapidement, il est non seulement plus économique mais aussi « meilleur » ! En effet, si un modèle est développé en 3 jours, il a bien plus de chances de coller à la réalité et aux besoins que s’il avait été développé en 6 mois, temps durant lequel la situation que l’on modélise va évoluer et rendre par conséquent le modèle plus ou moins obsolète dès sa sortie.
Il m’est même arrivé une fois qu’un client – l’Institut Géographique National (IGN) en la matière – vienne me voir après que deux des plus grandes sociétés de conseil françaises aient déclaré que leur problème ne pouvait pas être modélisé. Il s’agissait d’un modèle devant proposer le matin, en fonction de la carte météo, quels avions devaient partir faire quelles missions, à quels endroits, en se ravitaillant si nécessaire dans quels aéroports, en embarquant quels appareils d’enregistrement, et ce avec quel équipage…
Pour ceux qui aimeraient savoir comment j’ai modélisé cela (ou qui voudraient tout simplement apprendre plein d’autres choses sur la vraie modélisation, celle qui fait gagner de l’argent aux entreprises), il y a un chapitre de mon livre
« Comprendre et utiliser les modèles », aux Editions d’Organisation, qui est entièrement consacré à ce modèle. Pour acquérir un exemplaire de cet ouvrage, adressez un chèque de 35 € à mon ordre, en adressant la lettre à mon intention, à Logma SA – 12 rue d’Anjou – 78000 Versailles. Si vous commandez de l’étranger ou avez besoin d’une facture, contactez-moi par mail : thiriez@hec.fr.
Temps de calcul du modèle
On observe des écarts tout aussi significatifs entre le temps de calcul d’un modèle développé chez un client – que ce soit en interne ou par un autre prestataire – et le temps de calcul après que j’aie audité et amélioré le modèle.
Ce ne sont que trois exemples, mais il m’est souvent arrivé de diviser les temps de calcul des modèles que j’auditais par un facteur allant de 50 à 100.
Dans le dernier cas (EdF), où il s’agissait de consolider une quarantaine de classeurs Excel, il faut noter aussi que l’application originale comportait 400 pages de code Visual Basic – et était donc pratiquement impossible à auditer – alors que notre solution finale se contente de 8 pages de code, soit 50 fois moins…
Quand nous avons rapproché notre consolidation de celle effectuée avec l’ancien modèle sur les comptes de juin 2009 et de décembre 2009, nous avons trouvé un seul écart (de 600 K€ quand même !). Après analyse, il s’est avéré que l’erreur provenait de l’ancien modèle…
Taille du modèle
En ce qui concerne la taille des modèles, on observe une fois encore des écarts significatifs, comme on peut le constater dans le tableau ci-dessous :
Dans le cas de sanofi, le modèle concernait le « plan clinique », c’est-à-dire l’analyse et le suivi des médicaments en cours d’expérimentation. Au moment où j’ai réalisé le modèle, il y avait un classeur Excel par médicament, et il était quasiment impossible de consolider tout cela. J’ai mis en place un système permettant de tout regrouper en un seul classeur et – par conséquent – de rendre possibles toutes sortes de consolidations.
En ce qui concerne la taille du modèle, il m’est très souvent arrivé de parvenir à des économies de l’ordre d’un facteur 5 à 10.
Les outils décisionnels
De nombreux traitements, de nombreuses fonctionnalités, que l’on effectue aujourd’hui de façon coûteuse (il faut une licence par poste) avec des outils décisionnels peuvent parfaitement bien être réalisés avec Excel.
Nombreux sont mes clients qui, après être passés à un décisionnel, reviennent vers moi un ou deux ans plus tard pour me redemander des outils performants et personnalisés…
Une des raisons pour lesquels ces outils se vendent si bien malgré tout est qu’ils reçoivent l’adhésion totale de votre informatique maison (dont nous avons pu apprécier le niveau de performance dans le premier tableau) : quand vous utilisez ces outils, vos informaticiens sont utiles et donc valorisés ; quand vous utilisez Excel, vous parvenez à vous passer de leurs services, et ils n’aiment pas cela du tout. Pas étonnant donc qu’ils déclarent qu’Excel, « c’est du bricolage »…
En guise de conclusion…
On peut se demander comment il peut y avoir de tels écarts entre une modélisation classique et une modélisation performante. Il y a en fait plusieurs explications…
Tout d’abord, quand une société de conseil réalise un modèle, plusieurs personnes interviennent : le consultant qui analyse le problème et propose un devis, le chef de projet qui va coordonner la réalisation du produit, les développeurs qui vont programmer et enfin le formateur qui va assurer l’installation du modèle (parfois, c’est même quelqu’un d’autre qui fait cela !) et la formation. La coordination et le contrôle de tout ce joli monde représente du temps et pompe de l’énergie. Quand je développe un modèle, j’assure tout cela de A à Z, donc sans la moindre déperdition.
Une autre raison est que, dans toutes les écoles d’informatique, on enseigne la programmation structurée, en « top-down ». L’avantage de cette approche est qu’elle est organisée et systématique, et réduit donc le risque d’erreur.
Depuis plus de 40 ans, je pratique la programmation en « bottom-up », dans laquelle on développe d’abord un premier noyau, autour duquel on ajoute ensuite diverses fonctionnalités, puis d’autres encore, puis d’autres encore… et ce jusqu’à la fin du projet.
La raison pour laquelle cette approche n’est pas conseillée d’habitude est que, si le développeur n’a pas dès le début une vue d’ensemble de ce qu’il réalise et des possibles extensions futures, on aboutit rapidement à une « usine à gaz ».
En revanche, quand cela est bien fait, cela permet de développer bien plus vite qu’avec une approche « top-down ». De plus, contrairement au « top-down », on dispose à tout moment d’un modèle qui fonctionne, sur lequel on peut faire réagir le client, et qui permet donc d’améliorer le modèle au cours de son développement, ce qui est beaucoup plus difficile, sinon impossible, avec une approche « top-down ».
C’est grâce à cette approche « bottom-up » – que j’ai toujours pratiquée – et au fait que je réalise tout moi-même de A à Z, que j’ai pu aboutir aux écarts décrits ci-dessus.
En conclusion, sachez donc que vos modèles existants peuvent probablement être améliorés de façon sensible, et que vos futurs modèles pourraient être bien plus efficaces et bien moins chers, à condition toutefois de vous adresser pour les concevoir à des prestataires bien choisis…
J’ai commencé à développer des modèles pour les entreprises au début 1970, donc il y a plus de 40 ans. Diplômé de l’ENSIMAG, j’étais alors étudiant au MIT, pour un Ph.D. (doctorat) en recherche opérationnelle. J’ai créé ma première société de conseil, Flight Transportation Associates, quand j’étais encore étudiant. Toutes ces années de conseil représentent une certaine expérience :)
En plus de 40 ans, j’ai développé plus de 1.000 modèles, pour plus de 100 entreprises, dans plus de 10 pays. Au début en Fortran et en assembleur, puis sur Visicalc (le premier tableur, en 1979), Multiplan (à partir de 1982) et enfin – depuis 1985 – exclusivement sur Excel.
Ce qui m’a toujours frappé, c’est l’écart phénoménal que l’on peut constater entre des modèles créés par monsieur tout-le-monde et des modèles réellement performants : un modèle efficace est développé bien plus rapidement, se calcule sensiblement plus vite et occupe beaucoup moins de place en mémoire. Un modèle efficace représente donc une situation de win-win-win par rapport à un modèle lambda !
Temps de développement du modèle
Le tableau ci-dessous illustre quelques écarts entre les temps demandés pour un développement en interne et ceux que j’ai proposés en devis forfaitaire (et que j’ai tenus).
Notez l’excellente performance d’EdF : avec son écart représentant seulement un facteur 4, EdF est la société où j’ai trouvé le plus petit écart avec mon propre temps de développement.Chaque fois que je me suis trouvé en concurrence avec d’autres sociétés de conseil dans le cadre d’un appel d’offres, mon devis a toujours été entre 3 et 10 fois moins cher que celui du second moins-disant (je ne parle même pas des autres).
Quand un modèle est développé plus rapidement, il est non seulement plus économique mais aussi « meilleur » ! En effet, si un modèle est développé en 3 jours, il a bien plus de chances de coller à la réalité et aux besoins que s’il avait été développé en 6 mois, temps durant lequel la situation que l’on modélise va évoluer et rendre par conséquent le modèle plus ou moins obsolète dès sa sortie.
Il m’est même arrivé une fois qu’un client – l’Institut Géographique National (IGN) en la matière – vienne me voir après que deux des plus grandes sociétés de conseil françaises aient déclaré que leur problème ne pouvait pas être modélisé. Il s’agissait d’un modèle devant proposer le matin, en fonction de la carte météo, quels avions devaient partir faire quelles missions, à quels endroits, en se ravitaillant si nécessaire dans quels aéroports, en embarquant quels appareils d’enregistrement, et ce avec quel équipage…
Pour ceux qui aimeraient savoir comment j’ai modélisé cela (ou qui voudraient tout simplement apprendre plein d’autres choses sur la vraie modélisation, celle qui fait gagner de l’argent aux entreprises), il y a un chapitre de mon livre
« Comprendre et utiliser les modèles », aux Editions d’Organisation, qui est entièrement consacré à ce modèle. Pour acquérir un exemplaire de cet ouvrage, adressez un chèque de 35 € à mon ordre, en adressant la lettre à mon intention, à Logma SA – 12 rue d’Anjou – 78000 Versailles. Si vous commandez de l’étranger ou avez besoin d’une facture, contactez-moi par mail : thiriez@hec.fr.
Temps de calcul du modèle
On observe des écarts tout aussi significatifs entre le temps de calcul d’un modèle développé chez un client – que ce soit en interne ou par un autre prestataire – et le temps de calcul après que j’aie audité et amélioré le modèle.
Ce ne sont que trois exemples, mais il m’est souvent arrivé de diviser les temps de calcul des modèles que j’auditais par un facteur allant de 50 à 100.Dans le dernier cas (EdF), où il s’agissait de consolider une quarantaine de classeurs Excel, il faut noter aussi que l’application originale comportait 400 pages de code Visual Basic – et était donc pratiquement impossible à auditer – alors que notre solution finale se contente de 8 pages de code, soit 50 fois moins…
Quand nous avons rapproché notre consolidation de celle effectuée avec l’ancien modèle sur les comptes de juin 2009 et de décembre 2009, nous avons trouvé un seul écart (de 600 K€ quand même !). Après analyse, il s’est avéré que l’erreur provenait de l’ancien modèle…
Taille du modèle
En ce qui concerne la taille des modèles, on observe une fois encore des écarts significatifs, comme on peut le constater dans le tableau ci-dessous :
Dans le cas de sanofi, le modèle concernait le « plan clinique », c’est-à-dire l’analyse et le suivi des médicaments en cours d’expérimentation. Au moment où j’ai réalisé le modèle, il y avait un classeur Excel par médicament, et il était quasiment impossible de consolider tout cela. J’ai mis en place un système permettant de tout regrouper en un seul classeur et – par conséquent – de rendre possibles toutes sortes de consolidations.En ce qui concerne la taille du modèle, il m’est très souvent arrivé de parvenir à des économies de l’ordre d’un facteur 5 à 10.
Les outils décisionnels
De nombreux traitements, de nombreuses fonctionnalités, que l’on effectue aujourd’hui de façon coûteuse (il faut une licence par poste) avec des outils décisionnels peuvent parfaitement bien être réalisés avec Excel.
Nombreux sont mes clients qui, après être passés à un décisionnel, reviennent vers moi un ou deux ans plus tard pour me redemander des outils performants et personnalisés…
Une des raisons pour lesquels ces outils se vendent si bien malgré tout est qu’ils reçoivent l’adhésion totale de votre informatique maison (dont nous avons pu apprécier le niveau de performance dans le premier tableau) : quand vous utilisez ces outils, vos informaticiens sont utiles et donc valorisés ; quand vous utilisez Excel, vous parvenez à vous passer de leurs services, et ils n’aiment pas cela du tout. Pas étonnant donc qu’ils déclarent qu’Excel, « c’est du bricolage »…
En guise de conclusion…
On peut se demander comment il peut y avoir de tels écarts entre une modélisation classique et une modélisation performante. Il y a en fait plusieurs explications…
Tout d’abord, quand une société de conseil réalise un modèle, plusieurs personnes interviennent : le consultant qui analyse le problème et propose un devis, le chef de projet qui va coordonner la réalisation du produit, les développeurs qui vont programmer et enfin le formateur qui va assurer l’installation du modèle (parfois, c’est même quelqu’un d’autre qui fait cela !) et la formation. La coordination et le contrôle de tout ce joli monde représente du temps et pompe de l’énergie. Quand je développe un modèle, j’assure tout cela de A à Z, donc sans la moindre déperdition.
Une autre raison est que, dans toutes les écoles d’informatique, on enseigne la programmation structurée, en « top-down ». L’avantage de cette approche est qu’elle est organisée et systématique, et réduit donc le risque d’erreur.
Depuis plus de 40 ans, je pratique la programmation en « bottom-up », dans laquelle on développe d’abord un premier noyau, autour duquel on ajoute ensuite diverses fonctionnalités, puis d’autres encore, puis d’autres encore… et ce jusqu’à la fin du projet.
La raison pour laquelle cette approche n’est pas conseillée d’habitude est que, si le développeur n’a pas dès le début une vue d’ensemble de ce qu’il réalise et des possibles extensions futures, on aboutit rapidement à une « usine à gaz ».
En revanche, quand cela est bien fait, cela permet de développer bien plus vite qu’avec une approche « top-down ». De plus, contrairement au « top-down », on dispose à tout moment d’un modèle qui fonctionne, sur lequel on peut faire réagir le client, et qui permet donc d’améliorer le modèle au cours de son développement, ce qui est beaucoup plus difficile, sinon impossible, avec une approche « top-down ».
C’est grâce à cette approche « bottom-up » – que j’ai toujours pratiquée – et au fait que je réalise tout moi-même de A à Z, que j’ai pu aboutir aux écarts décrits ci-dessus.
En conclusion, sachez donc que vos modèles existants peuvent probablement être améliorés de façon sensible, et que vos futurs modèles pourraient être bien plus efficaces et bien moins chers, à condition toutefois de vous adresser pour les concevoir à des prestataires bien choisis…
rédigé par Hervé Thiriez |
4 commentaire(s)
C’est ce que nous avons fait ci-dessus en affichant dans la « pensée » le texte de la cellule G20. Pour cela, 
En sélectionnant la poignée jaune, nous avons, dans le premier cas, transformé le sourire en grimace et, dans le second, augmenté la partie du cercle utilisée.
Ce sont pratiquement toutes des formes que l’on trouvait dans Excel 2003, via la commande « Formes automatiques » de la barre d’outils « Dessins ». Deux rares nouveautés, au premier coup d’œil, la famille « Formes d’équation » et les objets en ¾ et en partie de cercle.
Nous voyons ci-dessus les trois formules entrées à cet effet en colonne E. Une fois de plus, nous constatons la grande variété des formules possibles dans Excel pour atteindre un même objectif… Seule la troisième formule doit être matricielle, c’est-à-dire validée avec la combinaison 
Le fait de protéger une feuille ne représente qu’un niveau assez faible de sécurité : on trouve aisément sur Internet les moyens de déprotéger une feuille de calcul, un classeur ou le code VBA d’un classeur.
Il faut ensuite utiliser la commande « Protéger la feuille », onglet « Révision », pour protéger la feuille, en ayant bien soin de désactiver la toute première commande, « Sélectionner les cellules verrouillées », comme dans la copie de dialogue ci-dessous :
Excel vous demande de confirmer le mot de passe après la validation de cette fenêtre. Ensuite, la feuille est protégée et seules les cellules déverrouillées sont alors accessibles.
