Available nodes

Cette page donne quelques recommandations quant aux attentes des encadrants de l'école par rapport aux projets, qu'il s'agisse des séances d'encadrement, des rapports ou des soutenances finales. Il ne faut pas la considérer comme une liste de recettes à appliquer, mais comme un ensemble de grandes lignes à suivre dans la démarche adoptée durant le projet.
Avertissement : ces conseils sont volontairement écrits de manière vague et abstraite. C'est au lecteur d'adapter la démarche à son problème, et pas le contraire.
La dernière section donne quelques exemples de choses à faire et à ne pas faire.

 La démarche scientifique

L'aspect primordial à établir consiste à faire preuve d'une démarche scientifique. Une telle démarche part du principe que pour répondre à une question ou résoudre un problème, il faut émettre des hypothèses et les soumettre à l'expérience, quitte à les modifier en fonction des résultats obtenus. Aucune allégation, aucun choix ne doit se faire de manière gratuite. Aucune conclusion ne doit être tirée sans se demander dans quelle mesure elle répond à la question initiale.

Pourquoi mettre en place une telle démarche ? Parce qu'elle demande à chaque étape de décrire ses choix, de les expliquer et de les remettre en cause. Comme pour une preuve scientifique, une telle attitude renforce considérablement la confiance que l'on peut placer dans le projet. A l'opposé, toute série d'affirmations gratuites rend le travail produit suspect.

Cette allégorie s'adapte naturellement à de nombreux contextes (surtout scientifiques), parmi lesquels on trouve le développement logiciel. Ainsi, face à un problème à résoudre, elle propose d'agir systématiquement de la manière suivante

  • Définir le problème précisément, ce qui en pratique demande de poser les définitions des objets considérés, d'évaluer l'existant et de le comparer au problème posé, et autant que possible de le décomposer en sous-problèmes indépendants, auxquels on appliquera la même méthode. En développement logiciel, on parlera d'analyse des besoins, fonctionnels ou non fonctionnels.
  • Établir des hypothèses, ce qui dans un projet de développement logiciel consiste à construire un ou plusieurs modèles abstraits censés répondre au problème, puis à planifier leur résolution. Comme les hypothèses, ces modèles sont faits pour être remis en cause au fur et à mesure de l'avancement du projet, mais ces remises en cause doivent absolument être justifiées par l'expérience ou le raisonnement.
  • Mettre en place un protocole de validation, qu'il s'agisse d'expériences, d'observations, ou de tests. Ce protocole peut être défini au tout début du projet, comme il peut évoluer au fur et à mesure de son avancement. Il sert de mètre-étalon pour vérifier si les résultats finaux permettent de valider les choix initiaux.
  • Justifier les résultats, c'est-à-dire comparer les besoins initiaux suivant le protocole de validation, et critiquer (au sens d'analyser objectivement) la pertinence desdits résultats. Cerner les limites du travail réalisé, et éventuellement proposer des pistes pour ses évolutions futures.
Et le code ? Une personne sagace se rendra compte que la démarche ne donne pas directement de place au fait même de réaliser le projet, en particulier le code même. C'est une illusion. Le code est une partie intrinsèque du projet. Lui aussi doit être analysé, justifié (par ses qualités), et potentiellement remis en cause (comme dans le cas de bug logiciel).

 Exemples et contre-exemples

Les points suivants donnent quelques idées permettant de mettre en place la démarche évoquée ci-dessus en utilisant les outils fournis dans la formation.
  • Systématiquement se référer à ses cours, les méthodes qu'ils décrivent sont toutes candidates pour décrire précisément votre démarche;
  • Les cours d'algorithmique proposent une démarche pour définir des objets algorithmiques, écrire, analyser et comparer les algorithmes, ainsi que des outils précis comme l'analyse de complexité;
  • Les cours de programmation proposent une démarche pour l'écriture de code (comme les conventions de codage), le développement logiciel en général (à travers des notions comme la modularité, la généricité ...), et en particulier test logiciel pour les cours plus avancés;
  • Toute réalisation admet un certain nombre de limites (pour une certaine valeur de "toute"), aucun projet ne peut se terminer sans évaluation critique;
  • Toute illustration d'une question par un exemple ou un dessin peut permettre de clarifier le propos.
  • Toute affirmation gratuite, tout dessin ou tout morceau de code non analysé, n'ont aucune valeur scientifique.
  • Toute expérience non reproductible n'est pas une expérience acceptable. Par corollaire, tout code qui ne fournit pas de méthode de compilation et d'exécution claire et stable est inutile.