TangenteX.com

Le mode projet

Les caractéristiques du mode projet

Définition du mode projet

Selon l'ISO (International Organization for Standardization), dans sa norme ISO 21500, un projet "est un ensemble unique de processus, constitués d’activités coordonnées et maîtrisées, ayant des dates de début et de fin et entreprises pour atteindre les objectifs du projet. La réalisation des objectifs du projet requiert la fourniture de livrables conformes à des exigences spécifiques ".  Il existe d'autres définitions, qui respectent toutes les fondements de ce qu'est un projet : un ensemble d'activités bornées dans le temps, qui visent à un objectif précis et qui donnent lieu à la fourniture de livrables.

Tout est dans cette définition, et en creux ce qui ne relève pas du mode projet :

Aujourd'hui, le mode projet est à la mode, et on entend dire à peu près n'importe quoi ! Munis de cette définition normalisée, vous serez capables de déterminer ce qui relève ou non du mode projet.

Histoire du mode projet

Les grandes constructions du passé, les cathédrales et autres palais et ponts, relèvent sans doute du mode projet, bien que certaines conditions ne soient pas forcément remplies, le bornage dans le temps par exemple.

Avec la révolution industrielle, et surtout à partir du milieu du XIXème siècle, l'organisation scientifique du travail apparut. Tout le monde connait F.W Taylor (pas le mathématicien, l'ingénieur), H.L Gantt et Henry Ford. Mais la formalisation du mode projet et des concepts attachés est survenue au milieu du XXème siècle. Ce sont les ingénieurs militaires chargés du développement des programmes spatiaux et d'armement qui construisirent le concept de "projet". Les premiers "projets" furent sans doute le programme Manhattan de construction de l'arme nucléaire et le débarquement du 6 juin 1944. Puis vinrent les programmes du DoD, du DoE et de la Nasa, et l'introduction de la méthode PERT (Program Evaluation and review technique) de planification par L'US Navy.

Aujourd'hui, pratiquement tous les produits, quelque soit leur nature, sont conçus en mode projet. Il est trés probable que vous utiliserez cette organisation de votre travail dans votre vie professionnelle et même personnelle.

Pourquoi travailler en mode projet

La principale raison de choisir le mode projet tient au le cadre méthodologique qu'il propose. Les méthodes de conduite de projet, de planification, d'analyse de risques, de spécification et autres sont très bien connues, sont enseignées dans toutes les écoles d'ingénieurs et dans les universités et font l'objet d'une littérature abondante.

Travailler en mode projet vous permet de disposer d'outils et de méthodes efficaces, qui vous guideront dans votre travail. Il s'agit de se concentrer sur le produit de votre projet, et de vous laisser guider par la méthode, sans trop y réfléchir !

Le mode projet, pour le peu que vous en respectiez les règles, vous permet aussi de mettre en oeuvre un langage commun avec vos interlocuteurs, et aussi des méthodes identiques ou du moins similaires. Un langage commun est un élément clé de la réussite d'un projet. J'ai trop souvent vu des projets s'enfoncer dans les difficultés parce que les acteurs de celui-ci ne partageaient pas le même vocabulaire, ni même la même sémantique.

Pour un étudiant, choisir le mode projet c'est apprendre à organiser son travail avec méthode, en suivre le déroulement et à en maîtriser tous les aspects fonctionnels et opérationnels.

C'est pour toutes ces raisons, que j'écris cette page et que je vous encourage vivement à vous plonger dans les différentes méthodes de gestion d'un projet.

La conduite d'un projet de simulation

Pour illustrer le concept de projet, je vais choisir un exemple de projet qui pourrait vous concerner. Imaginons que dans le cadre de votre TIPE vous aviez décidé de lier la mécanique des fluides et la thermodynamique et que vous aviez choisi d'étudier la formation des nuages sur un relief, autrement dit l'écoulement d'une masse d'air humide sur ce relief. J'ai déjà aborder le sujet de la formation des nuages dans une autre page de TangenteX.

Votre objectif est de produire un code qui simule l'écoulement, afin que vous puissiez déterminer les paramètres qui interviennent dans la formation de nuages au cours de cet écoulement.

Ce travail constituera la partie C (projet) de votre TIPE. Je n'insisterai pas ici sur les conseils pour présenter votre TIPE (voir cette page de TangenteX) mais plutôt sur l'organisation de ce travail.

Comme vous l'avez deviné, nous allons aborder ce travail en mode projet, car il s'agit bien d'un projet :

Les phases d'un projet de simulation

Les différentes phases d'un projet de réalisation d'un code de simulation, dans le cadre d'un TIPE ou d'un mémoire de master par exemple, peuvent se résumer ainsi :

Voyons maintenant ce que recouvre pratiquement ce jargon de chef de projet !

Définir les objectifs du projet

C'est la première étape fondatrice d'un projet : en définir les objectifs. Ils sont souvent de plusieurs natures :

Ces objectifs doivent être soigneusement définis et consignés dans un document de type "note de cadrage" ou "fiche projet" ou tout autre dénomination. Cette trace écrite est indispensable pour rappeler aux acteurs les finalités du projet, qu'ils ont souvent tendance à perdre de vue.

Les objectifs fonctionnels du projet

Dans notre hypothèse de travail, il s'agit de construire un logiciel de simulation de l'écoulement d'une masse d'air humide sur un relief, pour mettre en évidence les paramètres qui influent sur la formation des nuages.

Les objectifs fonctionnels du projet sont donc assez clairs. Ils sont de construire un logiciel qui :

Il existe d'autres objectifs du projet moins évidents :

Les objectifs économiques du projet

Dans notre exemple, les objectifs économiques ne sont pas financiers : à priori vous travaillez gratuitement pour vous-même. Mais il existe un objectif économique auquel vous n'échapperez pas : la charge de travail. Même si vous ne la valorisez pas, vous devrez vous fixer un objectif de charge de travail.

Evidemment, la charge de travail dépend des objectifs fonctionnels. Evidemment ... Ce n'est pas aussi simple ! Tout dépend des contraintes que vous vous imposez.

Dans tous les projets, il faut trouver un équilibre entre les objectifs fonctionnels, les ambitions du commanditaire du projet (vous, en l'occurence), et les ressources économiques disponibles pour le projet (votre temps disponible). Un bon équilibre est un garant majeur de la réussite du projet. Vouloir aller marcher sur la Lune avec un budget d'un milliard d'euros est un projet qui a peu de chance d'aboutir !

En général, il s'agit d'estimer la charge de travail que représente la réalisation de notre projet. Et ce n'est pas un exercice facile ! Presque toujours, on se trompe sur cette estimation, moi y compris. Alors, on prend de la marge, et si on mange la marge, alors on revoit les objectifs fonctionnels. Et si ceux-ci sont non négociables, on demande une révision des objectifs économiques, en clair une rallonge budgétaire. Une fois la charge estimée, il faut la valoriser, ce qui n'est pas le plus difficile.

Dans notre projet, point de valorisation de la charge, mais par contre il existe une contrainte forte : le délai. Si la charge estimée conduit à dépasser le délai incontournable de livraison du produit (l'épreuve du TIPE...), il reste la seule solution de la révision des objectifs fonctionnels...

Pratiquement, vous essayez d'estimer votre charge de travail de manière réaliste pour remplir les objectifs fonctionnels que vous vous êtes fixés. Attention à ne pas sous-estimer le boulot : voyez assez large. Cette charge est variable en fonction de votre maîtrise du sujet, de vos capacités de programmation, de votre habilité à la rédaction, etc. Disons entre 50 et 60 jours à la louche.

En possession de ce nombre, nous allons passer aux objectifs opérationnels.

Les objectifs opérationnels du projet

La début de fin du projet est incontournable : disons une semaine avant l'épreuve. Cet objectif au moins est facile à fixer. Reste quelques objectifs opérationnels auxquels vous pourriez réfléchir, par exemple :

Je suis parti de l'hypothèse que vous alliez travailler seul(e). Mais pourquoi pas en équipe ? Cela modifie la donne du problème... A envisager maintenant en organisant votre projet après en avoir fixé les objectifs.

Organiser votre projet

Travailler seul(e) ou en équipe ?

En règle générale, un projet se réalise en équipe, plus ou moins importante. D'ailleurs l'organisation et la gestion au quotidien d'une équipe projet est une des tâches principales du chef de projet, avec la gestion du budget.

Dans notre hypothèse de travail, la question se pose de la pertinence de travailler en groupe au sein du projet, rassembler une équipe projet, ou bien de travailler seul(e). Les deux types d'organisation ont leurs avantages et leurs inconvénients. C'est aussi une question de goût personnel.

Quels sont les éléments à prendre en compte pour choisir l'organisation ? Voici les principaux, à mon avis :

Pour ma part, je garde toujours en mémoire une citation que l'on attribut à Winston Churchill : "Un chameau est un cheval créé par un comité". Le travail en équipe c'est bien lorsque tous les membres de l'équipe partagent les mêmes objectifs et la vision pour y parvenir. Lorsqu'ils comprennent tous de la même manière les exigences et spécifications qui ont été rédigées. Et d'expérience, je peux vous dire que ce n'est pas gagné !

Pour les grands projets, on ne peut pas éviter la construction d'une équipe projet. Pour le type de projet que nous envisageons, personnellement, je choisis le travail solitaire. C'est une affaire de goût mais aussi une façon certaine d'acquérir toutes les compétences qui feront de vous un bon professionnel.

Evaluer les ressources

Supposons que vous travailliez seul(e). Le bilan des ressources humaines est rapide : vous et votre capacité de travail. Rapide mais pas forcément simple !

Dans le délai que vous vous êtes fixé lors de l'établissement des objectifs, vous disposez d'un certain temps à consacrer à votre projet. Quel temps ? Une ou deux heures par jours, en moyenne ? Plus, moins ? A déterminer par vous ! La quantité de temps total que vous obtiendrez représente vos ressources, que vous devrez mettre en regard de la charge de travail que vous estimerez pour tenir vos objectifs fonctionnels.

D'autres ressources vous serons nécessaires :

A vous de les identifier et de vous assurez qu'ils seront disponibles lorsque vous en aurez besoin...

Construire un planning

C'est une technique, un art, et la source de pratiquement toutes les difficultés dans un projet ! Pour construire un planning, il faut :

  1. identifier les différentes activités du projet, dans toutes ses phases,
  2. identifier les enchainements entre activités et les contraintes que peuvent engendrer une activité sur une autre,
  3. identifier et quantifier les ressources nécessaires à la réalisation de chaque activité,
  4. calculer la charge et le délai d'exécution de chaque activité,
  5. vérifier si le planning obtenu est conforme aux objectifs. Si non, repartir de l'étape 3

C'est un exercice délicat, qui ne va pas sans risque. Un planning mal construit mène toujours à des difficultés lors du déroulement du projet.

Une chose essentielle  : faites un planning REALISTE ! N'essayez pas de faire plaisir à Paul ou Jacques en réduisant vos délais ou votre charge : cela conduit inévitablement à la catastrophe. Vous vous apercevrez avec l'expérience que vos premières estimations sont très souvent les bonnes et qu'il est inconscient de vouloir les réduire.

Autre chose essentielle : même sur un projet solitaire, un "petit" projet, prenez le temps de faire régulièrement l'état d'avancement de votre planning. Voyez si vous êtes en avance ou si vous dérapez. Dans ce cas, prenez les mesures qui s'imposent pour maîtriser le dérapage (ne pas prendre une semaine de retard toutes les semaines) et pour le rattrapper (ajuster les objectifs, augmenter les moyens en se faisant aider, etc..).

Pour information, il existe des logiciels en open source qui vous permettent de construire et de suivre un planning, par exemple GanttProject. Apprenez à vous en servir, cela vous sera utile plus tard !

Le Plan Projet

Le Plan Projet est un document dans lequel sont consignées toutes les informations d'organisation du projet, y compris le planning prévisionnel (celui du début du projet) et le planning actualisé au cours du projet.

Evident dans les grands projets, il devrait être produit dans tous les projets. Pour notre projet de simulation, je vous recommande vivement de rédiger ce document. Pas besoin d'en faire des tonnes ! Quelques pages dans lesquelles vous décrirez l'organisation de votre projet, les méthodes que vous utilisez, les outils que vous avez mis en oeuvre dans le suivi de votre projet, les ressources engagées et votre planning.

Lors de la présentation de votre projet à un jury, n'hésitez pas à évoquer ce document, voire à lui consacrer une slide dans votre présentation.

La phase de modélisation

Nous voilà dans la partie "métier" du projet ! L'organisation est sur les rails, il s'agit maintenant de produire...

Bien poser le problème

L'objectif fonctionnel de notre projet est "d'étudier l'écoulement d'une masse d'air humide sur un relief". 

C'est assez (trop) général ! Vous devez circonscrire le problème posé dans les contours qui vous permettront de réaliser le projet dans les objectifs économiques et opérationnels que vous vous êtes fixés.

Par exemple, vous pouvez vous limiter à une étude dans le plan, sur des reliefs simples. Vous pouvez fixer dans leurs grandes lignes des hypothèses simplificatrices dont vous tiendrez compte dans la construction de votre modèle.

Vous devrez également vérifier que vous disposez bien des outils théoriques pour aborder correctement le problème et que vous les maîtrisez ou que vous pourrez en acquérir la maîtrise. Rien n'est plus agaçant pour un jury de TIPE ou de Master que de s'apercevoir que l'étudiant ne maîtrise pas les concepts qu'il expose !

Définir le modèle physique

Il s'agit d'établir le modèle physique du phénomène à simuler, afin de pouvoir concevoir un outil de simulation qui réponde à nos besoins.

Pemière étape : poser les hypothèses simplificatrices qui vous permettront de traiter le problème sans vous perdre dans des complexités inutiles. C'est sans doute l'étape la plus difficile car elle détermine la pertinence de votre modèle et son efficacité.

Seconde étape : établir les lois de la physique que vous allez invoquer.

Enfin, poser les équations déduites de ces lois et des hypothèses simplificatrices. Les réduire, les simplifier, pour obtenir un jeu d'équations qui modélisent au mieux le phénomène physique que vous voulez simuler. Vous devrez également noter les limites de votre modèle, qui découlent des hypothèses simplificatrices que vous avez faites. Elles pourraient aussi découler d'une insuffisance théorique, mais c'est assez peu probable dans le phénomène que nous étudions !

Documenter votre modèle

C'est le moment de produire un des documents les plus importants de votre projet. En règle générale, nous appelons ce document "spécifications" du système ou du produit. Ce document décrit les caractéristiques fonctionnelles du produit, qui découlent des besoins que le produit doit satisfaire. On y retrouve les "exigences" mentionnées dans la définition d'un projet.

Dans notre cas d'étude, le document de spécification décrira le phénomène à étudier puis sa modélisation, en mentionnant l'ensemble des informations pertinentes sur le sujet : les bases théoriques du modèle, leur justification, les limites du modèle, etc.

Attachez beaucoup de soin à la rédaction de ce document. Il vous servira de base à une présentation à un jury, et au delà, il vous permettra de capitaliser sur vos acquis. Et si un jour vous entrepenez une thèse, vous aurez pris les bonnes habitudes...

La phase de développement

Passer du modèle au logiciel

A l'issue de la phase de modélisation, vous disposez d'un modèle physique solide du phénomène à simuler. Il vous reste maintenant à traduire ce modèle en un ensemble de moyens capables de le simuler.

On pourrait, et ça serait assez original de nos jours, décider de construire un calculateur analogique pour simuler notre modèle. Ne riez pas, cela se faisait encore dans les années 80 et c'était très intéressant. Encore aujourd'hui, dans certains cas très particuliers, on utilise des calculateurs analogiques, faits de sommateurs, d'intégrateurs, de dérivateurs et de potentiomètres. Une idée à creuser pour un TIPE : l'actualité des calculateurs analogiques...

Restons classiques et transcrivons notre modèle en un code informatique exécutable sur PC ou mieux Mac :-).

Vous allez tout d'abord devoir choisir les grandes lignes de votre méthode : allez-vous choisir la méthode calculatoire et résoudre une collection d'équations différentielles ? Ou choisir une autre méthode comme l'usage des automates cellulaires ou d'un algorithme génétique ? Tout dépend du modèle. Dans notre cas, vous en resterez probablement à la méthode calculatoire. L'utilisation d'un automate cellulaire reste cependant une alternative à étudier...

Pour rester dans notre cas d'étude, j'imagine que vous allez choisir la méthode des différences finies et résoudre vos équations dans le maillage que vous aurez définis. Il vous faudra mettre en oeuvre les bons algorithmes et démontrer que leur usage est légitime. N'hésitez pas à vérifier que ces algorithmes sont pertinents par une petite étude numérique !

En tous les cas, tracez dans un document tous vos choix et leurs justifications : cela vous servira pour présenter votre travail mais aussi pour capitaliser votre savoir-faire et l'exploiter plus tard.

Développer le logiciel

Ne vous précipitez pas sur votre clavier, tout à votre enthousiasme de pondre des lignes de codes ! Je vous recommande vivement de vous poser et de réfléchir à la manière dont vous allez organiser votre logiciel, le coder et le tester.

Construire la structure générale du logiciel

Un logiciel de simulation dans le cadre d'un projet universitaire présente une structure relativement simple. Il se décompose en plusieurs parties :

Il est très probable que votre code ressemblera à ça. La seule difficulté consiste à bien choisir le niveau de décomposition des fonctions. Une bonne habitude est d'écrire le code d'une fonction pour qu'il tienne sur une page A4 : cela facilite la lecture !

Coder et tester chaque fonction

Il est très probable que vous serez amené à partager votre code, et peut-être à le présenter à un jury. Alors écrivez un code clair, aéré et bien commenté. Préférez la lisibilité aux astuces qui, pensez-vous améliorent les performances, mais qui rendent illisible et incompréhensible un code, pour les autres comme pour vous au bout de quelques temps. Pour ma part, je considère qu'à la lecture d'une fonction, je dois pouvoir reconnaitre l'algorithme mis en oeuvre et ses différents paramètres. Dans le cas contraire, je poubellise !

Vérifiez que vous traitez dans votre code toutes les exceptions qui pourraient survenir, tant au niveau des entrées/sorties (fichier absent, erreur de lecture/écriture disque ou réseau, etc.) que des calculs (dépassement capacité, division par zéro, etc.).

Assurez-vous que les fonctions que vous programmez soient autonomes et testables. Autonomes, c'est à dire qu'elles ne dépendent pas de variables globales (à éviter autant que possible) et qu'elles puissent fonctionner avec un appel unitaire. Qu'elles soient testables, c'est à dire que vous soyez capable de vérifier leur bon fonctionnement en introduisant des paramètres d'entrés connus pour obtenir des résultats prévisibles.

Testez vos fonctions une à une. Utilisez le code minimum nécessaire pour initialiser les variables d'entrée de la fonction, appeler la fonction et visualiser les variables retournées par votre fonction. Pour tester votre fonction :

Lorsque vous aurez testé toutes vos fonctions, il sera temps de passer à l'étape suivante.

Intégrer les fonctions dans le logiciel

Toutes vos fonctions sont OK individuellement, il reste à vérifier qu'elles arrivent à bien travailler ensemble ! Vous allez donc les réunir dans votre programme, c'est l'étape d'intégration du logiciel.

Mais me direz-vous, pourquoi des composants logiciels fonctionnant correctement individuellement pourraient ne pas fonctionner ensemble ? Il existe plusieurs raisons, qui sont autant de bugs qui vous trouverez sans doute un jour :

Ce sont les principales, mai il y en a d'autres, plus exotiques, que je vous laisse découvrir...La programmation est un des domaines d'application privilégiés de la loi de Murphy : tout ce qui peut se planter se plantera !

Tester et valider le logiciel intégré

Les tests qui vous ferez subir à votre logiciel après son intégration sont destinés à découvrir ces bugs et à les corriger. On les nomme "tests d'intégration" et il ne faut surtout pas les bâcler.

Bon, après quelques heures, voire quelques jours pénibles, votre code de simulation fonctionne, du moins les tests unitaires et d'intégration sont OK.

Reste maintenant à valider le tout en lançant une vraie simulation avec des paramètres réalistes. En principe, cela devrait fonctionner dans les grandes lignes. Mais vous trouverez sans doute des petites améliorations à faire, dans les affichages graphiques ou même sur les temps de calcul. Ce dernier point est délicat, car améliorer le temps de calcul peut conduire à changer de méthode de programmation (en Python, passer des boucles à la vectorisation, voir ici par exemple) ou pire à changer d'algorithme !

Il est peu probable que, dans le cas d'un projet de TIPE ou de mémoire comme nous l'imaginons ici, le temps de calcul soit une préoccupation majeure. Mais il peut être enrichissant de montrer que vous vous êtes posé la question et que vous avez exploré même succinctement quelques voies...

Voilà, votre code est testé et validé. Reste maintenant à l'exploiter !

Le choix des outils de développement

Ce sont ces détails qui font la vie d'un projet... Par exemple, choisir le langage et l'environnement de développement que vous utiliserez pour coder !

Vous devrez choisir un langage capable de faire du calcul sans trop se traîner, mais aussi qui dispose d'une bonne libraire graphique. S'il dispose en plus d'une bonne librairie scientifique, alors c'est encore mieux.

A vrai dire, le choix n'est pas très grand. En gros, Matlab, Scilab ou Maple pour les outils classiques dans les lycées et les grandes écoles ou un langage universel comme Python. Vous pouvez aussi utiliser C++ à condition de posséder une bonne librairie graphique et scientifique, comme la librairie ROOT du CERN par exemple.

Le mieux est d'utiliser un langage que vous connaissez bien, s'il convient à vos besoins bien sûr. Si vous débutez dans le développement de logiciel, je vous conseille Python et l'environnement de développement Anaconda, très répandu dans les milieux universitaires et dans les labos des entreprises. Si vous avez les moyens, MatLab est aussi un bon choix, mais la licence est hors de prix !

La documentation

Il serait dommage de perdre la mémoire de la somme d'expérience et de savoir-faire que vous avez acquis lors de la réalisation de votre projet ! Chaque projet est une source de richesses exploitable dans l'avenir, à condition de savoir la formaliser et l'organiser. C'est l'objet de la documentation.

A quoi sert la documentation d'un projet

Disons d'abord que la documentation d'un projet concerne deux aspects du projet : le déroulement du projet et le produit du projet, en l'occurence votre code de simulation.

Commençons par la documentation sur le déroulement du projet. Son objet est de conserver l'histoire du projet, de son déroulement et des différentes difficultés que vous avez pu rencontrer. Dans notre cas, cette documentation sera sans doute peu importante. Dans le cadre d'un TIPE ou d'un mémoire de master, il n'est pas impossible qu'un membre du jury vous demande comment vous avez conduit votre projet. Dans ce cas, la production d'un plan projet, d'un planning et d'une analyse de risques sera du meilleur effet ! Pour ma part, de mes projets, je conserve toujours le Plan de Projet, le planning prévisionnel et les planning actualisés (on rigole souvent en le lisant a posteriori) et l'analyse de risques pour autant qu'elle ait été actualisée régulièrement.

La documentation sur le produit est autrement plus importante ! Elle retrace les différentes phases de développement de votre code, les hypothèses qui ont conduit à ce qu'il est, les astuces algorithmiques ou de programmation, vos tests et les différents paramètres qui permettent son utilisation. Cette documentation doit être soignée, précise, complète et facilement accessible. Elle est un gage de la bonne qualité du produit et aussi des compétences du concepteur. Je préfère de loin, et c'est une opinion partagée dans la profession, un code sans originalité mais propre, robuste et bien documenté, à un code génial mais hermétique. Certains pensent que c'est une marque de génie que de créer un code hermétique, en fait c'est irresponsable. Un code hermétique est inexploitable et généralement poubellisé au départ de son concepteur. J'aurais même tendance à poubelliser aussi le concepteur, sauf exception exceptionnelle...

Bref, documentez bien votre code dans toutes ses phases de conception (étude, développement, tests) et conservez cette documentation. Là aussi, un jury de TIPE ou de master peut très bien demander à voir votre code et sa documentation !

La documentation minimum d'un projet

Pour un projet d'étude, TIPE ou mémoire de master, la documentation minimum est :

Cette documentation devra être disponible sous format électronique, en format .doc et .pdf.

Dans votre vie professionnelle future, si vous développez du code, vous retrouverez sensiblement les mêmes exigences de documentation.

La gestion des acquis

Lors du déroulement de votre projet, vous avez rencontré des difficultés, vous avez découvert des astuces, des erreurs à ne pas commettre, des actions à mener obligatoirement. Bref, vous avez acquis de la connaissance. C'est ainsi que se construit l'expérience, qui vous exploiterez lors de vos prochains projets. A condition de l'avoir mémorisée et de savoir la ressortir au bon moment !

Vous pouvez certes vous fier à votre mémoire, mais il est parfois plus sûr de consigner tout ça par écrit. En physique, c'est le rôle du cahier de laboratoire. Les informaticiens appellent ça pompeusement le 'knowledge management'. Il s'agit de consigner de façon claire et précise les différentes expériences heureuses et malheureuses que vous avez vécu pendant votre projet, de façon à pouvoir exploiter dans les projets suivants vos acquis.

Le formalisme importe peu du moment que les informations soient exploitables. J'ai trop de systèmes de KM (le knowledge management...) compliqués et lourds, inexploités parce qu'inexploitables ! Pour ma part, j'en suis resté au cahier à spirale ! Certains des lecteurs qui me connaissent vont être surpris, je suis d'habitude 0-papier !

Débuter votre simulation

Il est grand temps de passer à la physique, non ? Votre projet est terminé, vous avez atteint vos objectifs : disposer d'un logiciel qui satisfait à vos besoins "métier", le tout dans le temps prévu par votre planning et sans dépenser plus de ressources que prévu. Bravo !

Et maintenant ? Parce qu'un projet n'est jamais une fin en soi (sauf pour le chef de projet) : il doit produire un instrument opérationnel pour un ou des utilisateurs qui le mettront en oeuvre dans leur métier.

Considérez votre code de simulation comme un instrument de laboratoire qui vous permet de faire des expériences. Et donc, procédez comme vous procéderiez devant un instrument posé sur une paillasse. Comme au labo, préparez votre expérience en choisissant les différents paramètres de votre simulation. Puis lancez la simulation, faites l'expérience, notez son déroulement et enregistrez les résultats. Comme au labo, tenez un cahier de laboratoire sur lequel vous consignerez les valeurs d'entrée de la simulation et les résultats obtenus et toutes les observations pertinentes, le temps de calcul ou les erreurs logicielles, par exemple.

Vient alors le travail d'interprétation des résultats : sont-ils réalistes ? Que nous disent-ils ? Comment les interroger avec les outils théoriques mis en oeuvre ? Sont-ils affectés par les hypothèses simplificatrices de notre modèle ? En quoi ?

Parce que le travail de modélisation n'est jamais achevé ! Vos résultats montreront sans doute les limites de votre modèle, des phénomènes jugés marginaux ou sans importance, qui en possèdent sans doute une...

Alors, vous tenterez d'améliorer votre modèle et vous lancerez un nouveau projet ! C'est le cycle de vie de tous les physiciens numériciens : améliorer les modèles ou même parfois, tout jeter et recommencer ! Bienvenue au club !

Contenu et design par Dominique Lefebvre - www.tangenteX.com septembre 2019 Licence Creative Commons Contact :