Modélisation – Remarques finales

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 potentiel dans le premier tableau du premier article de cette série) : 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 s’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 45 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 dans cette série d’articles.

C’est assez amusant de constater que les méthodes « agiles », créées en 2001 et à la mode depuis quelques années, reposent en bonne partie sur ces principes qui m’ont toujours guidé.

En conclusion, sachez donc que vos modèles Excel existants peuvent probablement être améliorés de façon notable, 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…