Conduire un projet
Cours complet · NSI (première), chapitre 11 · première, spécialité numérique et sciences informatiques
Travailler ce chapitre sur Adloun Exercices corrigés de ce chapitre
« Une part de l'horaire de l'enseignement d'au moins un quart du total en classe de première doit être réservée à la conception et à l'élaboration de projets conduits par des groupes de deux à quatre élèves. » — Programme de NSI
Un quart de l'année. Ce chapitre n'est donc pas un appendice : il décrit ce à quoi une séance sur quatre est consacrée. Le programme en donne la raison — « un enseignement d'informatique ne saurait se réduire à une présentation de concepts ou de méthodes sans permettre aux élèves de se les approprier en développant des projets applicatifs ».
Les dix chapitres précédents ont fourni les outils. Celui-ci dit comment s'en servir sans que le groupe s'effondre en cours de route.
11.1 Choisir un sujet
Le programme est explicite : « dans la mesure du possible, il convient de laisser le choix du thème du projet aux élèves eux-mêmes ». Un sujet choisi est mené ; un sujet imposé est subi.
Les pistes que cite le programme, à titre d'exemples :
- un approfondissement théorique d'un concept étudié en commun ;
- une application à une autre discipline — simulation d'expérience, traitement de données socio-économiques ;
- un logiciel de lexicographie ;
- un projet autour d'un objet connecté ou d'un robot ;
- une bibliothèque implémentant une structure de données complexe ;
- un problème de traitement d'image ou de son ;
- une application mobile, par exemple de réalité virtuelle ou augmentée ;
- un site Web associé à l'utilisation d'une base de données ;
- la réalisation d'un interprète d'un mini-langage ;
- un programme de jeu de stratégie.
Le programme la nomme sans détour : « les professeurs veillent à ce que les projets restent d'une ambition raisonnable afin de leur permettre d'aboutir ».
Un projet trop grand ne produit pas un demi-résultat : il ne produit rien. Trois quarts d'un jeu ne se jouent pas ; les trois quarts d'un site ne s'ouvrent pas. Mieux vaut un morpion qui fonctionne, se teste et se présente, qu'un jeu de stratégie dont il ne restera que des morceaux.
Méthode : Le test du noyau minimal
Avant de vous engager, écrivez en une phrase ce que fera votre programme dans sa version la plus dépouillée — celle qui, seule, mérite encore d'être montrée. Si cette phrase demande un « et » de plus, c'est déjà trop.
Puis dressez à côté la liste des extensions souhaitables. Elles viendront après, si le temps le permet. Un projet se construit du noyau vers l'extérieur, jamais l'inverse.
d'échec que le programme nomme lui-même : l'ambition déraisonnable.</div>
11.2 Spécifier avant de coder
Tout le chapitre 3 s'applique, à l'échelle du groupe cette fois. Le document de départ tient en une page et répond à quatre questions.
| Question | Ce qu'on écrit |
|---|---|
| Que fait le programme ? | une phrase, du point de vue de l'utilisateur |
| Quelles données entrent, quelles données sortent ? | formats précis |
| Comment sait-on qu'il marche ? | les cas de test, écrits avant le code |
| Qu'est-ce qui n'en fait pas partie ? | la liste de ce qu'on renonce à faire |
La quatrième ligne est celle qu'on oublie, et c'est la plus utile. Écrire noir sur blanc « le programme ne gère pas plusieurs joueurs en réseau » évite trois semaines de discussions et un abandon en février.
11.3 Découper, répartir, assembler
Un projet à plusieurs ne se découpe pas au hasard : ce sont les interfaces, fixées d'avance, qui permettent à chacun d'avancer sans attendre les autres.
Méthode : Découper en modules qui se testent seuls
Le découpage réussi n'est pas celui qui répartit équitablement le travail : c'est celui où chaque morceau peut être écrit et testé sans attendre les autres. Pour un jeu sur grille, par exemple :
| Module | Interface | Se teste seul ? |
|---|---|---|
| grille | `creer`, `lire`, `ecrire` | oui |
| règles | `coup_legal`, `appliquer`, `gagnant` | oui |
| affichage | `afficher(grille)` | oui |
| partie | enchaîne les trois | en dernier |
Chaque module est défini par ses prototypes — noms, arguments, résultats — fixés ensemble au début. C'est ce contrat qui permet à deux personnes de travailler en parallèle : celle qui écrit l'affichage n'a pas besoin que les règles soient finies, elle a besoin de savoir ce que grille lui donnera.
Répartir sans fixer les interfaces d'abord conduit invariablement au même désastre : trois morceaux qui fonctionnent séparément et refusent de s'emboîter, découvert la veille de la présentation. Les prototypes se décident avant la première ligne de code, et se notent.
11.4 Les points d'étape
Le programme les impose : « la gestion d'un projet inclut des points d'étape pour faire un bilan avec le professeur, valider des éléments, contrôler l'avancement du projet ou adapter ses objectifs, voire le redéfinir partiellement, afin de maintenir la motivation des élèves ».
Notez ce que dit cette phrase : un point d'étape peut conclure qu'il faut réduire le projet. Ce n'est pas un échec, c'est le mécanisme normal. Le seul vrai échec est de s'en apercevoir trop tard.
| Étape | Ce qui doit exister | Décision possible |
|---|---|---|
| 1 | le sujet, le noyau minimal en une phrase | recentrer |
| 2 | les prototypes des modules, les cas de test | redécouper |
| 3 | un module qui tourne et passe ses tests | réduire la suite |
| 4 | le noyau minimal complet | ajouter des extensions |
| 5 | tests, corrections, présentation | geler le code |
qu'il faut « adapter ses objectifs, voire le redéfinir partiellement ».</div>
Méthode : Le journal de bord
Tenir, à plusieurs, un fichier où l'on note à chaque séance : ce qui a été fait, ce qui bloque, ce qui a été décidé et pourquoi. Dix lignes par séance suffisent.
Ce document sert trois fois : à retrouver pourquoi telle décision a été prise, à rédiger la présentation sans rien reconstituer de mémoire, et à établir la part réelle de chacun.
11.5 Tester, jusqu'au bout
Le chapitre 3 l'a établi : « le succès d'un jeu de tests ne garantit pas la correction d'un programme ». Cela ne dispense pas de tester — cela oblige à tester bien.
# tests_grille.py — écrit AVANT grille.py, et exécuté à chaque séance
from grille import creer, lire, ecrire
def test_creation():
g = creer(3, 3)
assert len(g) == 3 and len(g[0]) == 3
assert all(lire(g, i, j) == 0 for i in range(3) for j in range(3))
def test_ecriture_independante():
"""Le piège du chapitre 4 : deux lignes ne doivent pas être la même."""
g = creer(2, 2)
ecrire(g, 0, 0, 5)
assert lire(g, 1, 0) == 0, "les lignes partagent la meme memoire !"
def test_hors_grille():
g = creer(3, 3)
refuse = False
try:
ecrire(g, 5, 0, 1)
except AssertionError:
refuse = True
# Le verdict est HORS du try : un assert placé dedans serait avale
# par le except, et le test passerait quoi qu'il arrive.
assert refuse, "aurait du refuser une case hors grille"
for test in (test_creation, test_ecriture_independante, test_hors_grille):
test()
print("ok", test.__name__)Méthode : Trois habitudes qui sauvent un projet
- Rejouer tous les tests à chaque séance, pas seulement ceux du module qu'on vient de toucher. Une correction en casse souvent une autre ailleurs.
- Garder une version qui marche. Avant toute modification importante, conserver une copie datée. Une version dégradée mais fonctionnelle vaut infiniment mieux qu'une version améliorée qui ne démarre plus la veille de la présentation.
- Écrire le test avant la correction. Devant un défaut, produire d'abord le cas qui le déclenche. On sait alors qu'il est réellement corrigé — et qu'il ne reviendra pas.
11.6 Présenter
Le programme range la présentation parmi les compétences transversales : « présenter un problème ou sa solution, développer une argumentation dans le cadre d'un débat ».
| Moment | Ce qu'on montre |
|---|---|
| Le problème | ce qu'on a voulu faire, et pourquoi ce sujet |
| La démonstration | le programme qui tourne, sur un cas préparé |
| Les choix | deux ou trois décisions techniques, et leurs raisons |
| Les limites | ce qui ne marche pas, et ce qu'on sait en dire |
| Le partage du travail | qui a fait quoi, honnêtement |
Un groupe qui annonce « notre détection de fin de partie échoue sur les diagonales, nous savons pourquoi et voici ce qu'il aurait fallu faire » montre qu'il a compris son programme. Un groupe qui présente une démonstration soigneusement choisie pour éviter le défaut montre l'inverse.
C'est la même exigence que la docstring honnête du chapitre 5 : ne promettez pas plus que ce que vous garantissez.
11.7 Une grille pour s'auto-évaluer
| Critère | Ce qu'on vérifie |
|---|---|
| Aboutissement | le noyau minimal fonctionne de bout en bout |
| Spécification | chaque fonction a son prototype, ses préconditions, sa docstring |
| Tests | un jeu de tests existe, couvre les cas limites, et passe |
| Structure | le découpage en modules est net ; aucun ne dépend des détails d'un autre |
| Correction | les boucles non bornées ont un variant identifié |
| Travail collectif | le journal de bord montre une contribution réelle de chacun |
| Honnêteté | les limites sont connues, mesurées et annoncées |
Cette grille n'invente rien : chaque ligne renvoie à un chapitre. Spécification et tests au chapitre 3, structure aux chapitres 4 et 5, variants au chapitre 7, honnêteté partout. Un projet réussi n'est pas un exercice de plus — c'est la mise en œuvre simultanée de tout ce qui précède.
Repère historique : Pourquoi les projets informatiques échouent
La question n'est pas scolaire. En 1968, une conférence de l'OTAN à Garmisch réunit les informaticiens autour d'un constat brutal : les grands programmes livrent en retard, coûtent plus que prévu et fonctionnent mal. C'est là qu'est forgée l'expression génie logiciel, pour désigner ce qui manquait alors — une discipline de conception, et pas seulement l'art de coder.
Les causes relevées à l'époque sont exactement celles qui menacent un projet de première : spécification floue, ambition mal calibrée, modules qui ne s'emboîtent pas, tests repoussés à la fin. Un demi-siècle plus tard, les remèdes n'ont pas changé — écrire ce qu'on va faire, découper, tester tôt, mesurer l'avancement.