Un cap pour ce chapitre
Ce que vous saurez faire
- Formuler un besoin et un périmètre réalisable.
- Répartir des responsabilités avec des interfaces.
- Prévoir validation, intégration et présentation.
Décrire un usage concret
« Faire une application de sport » est trop large pour orienter un travail. « Permettre à un élève d’enregistrer ses temps de course et de voir leur évolution » identifie un utilisateur, des données et un résultat. Une première version peut accepter des valeurs saisies simplement et afficher un tableau avant d’ajouter un graphique.
Le périmètre minimal doit déjà rendre un service complet, même modeste. Distinguez les fonctions indispensables, les améliorations souhaitées et les idées reportées. Cette hiérarchie permet d’adapter le projet sans perdre tout son intérêt si une difficulté technique prend plus de temps que prévu.
Un critère de réussite doit être observable : « avec trois temps fictifs, l’application affiche leur moyenne et refuse une valeur négative ». « L’application sera intuitive » exprime une intention mais ne fournit pas ce test. Écrivez le scénario qui permettra à une autre personne de constater que le besoin est satisfait.
Découper selon les responsabilités et les échanges
On peut séparer l’acquisition des données, leur stockage, les calculs et l’affichage. Les membres du groupe doivent se mettre d’accord sur la représentation échangée : noms des champs, unités, types et comportement sur des données manquantes. Une interface écrite évite que chacun produise un composant correct isolément mais incompatible avec les autres.
La répartition ne doit pas enfermer une seule personne dans toute la compréhension technique. Chacun peut avoir une responsabilité principale et expliquer régulièrement son travail aux autres. Une revue courte d’un exemple d’entrée et de sortie révèle souvent une divergence avant qu’elle ne coûte beaucoup de temps.
Intégrer une petite version tôt
Attendre la dernière séance pour assembler tous les composants est risqué. Construisez rapidement un trajet complet avec un petit jeu de données : saisir, calculer puis afficher. Cette version montre si les interfaces sont compatibles et fournit une base qui peut être améliorée progressivement.
Les tests portent sur les règles importantes : une mesure négative doit-elle être refusée ? Une liste vide doit-elle afficher un message ? Les unités sont-elles cohérentes ? Un jeu de données fictives bien choisi permet de vérifier le comportement sans utiliser les informations personnelles de camarades. Conservez des versions identifiables pour retrouver un état fonctionnel.
Faire des points d’étape utiles
Un point d’étape répond à quatre questions : qu’est-ce qui fonctionne réellement, comment l’a-t-on vérifié, qu’est-ce qui bloque et quelle est la prochaine petite réalisation ? Une liste de fonctionnalités annoncées ne remplace pas une démonstration. Si le périmètre change, mettez aussi à jour la description et les tests.
La présentation finale explique le besoin, l’organisation, un choix technique et une limite. La documentation permet de lancer le projet et de comprendre ses composants. Les projets font partie intégrante de l’enseignement de NSI ; leur ambition doit rester compatible avec le temps et les moyens disponibles, comme le souligne le programme officiel.
Exemple suivi : une première version de suivi de courses
Le besoin retenu est d’enregistrer des temps en secondes et de comparer deux séances. La première version accepte une liste de nombres fictifs, calcule une moyenne et affiche un tableau. Le contrat de calcul reçoit une liste non vide de nombres strictement positifs, sans la modifier. Le composant de saisie transforme le texte en nombres et explique les refus. La présentation affiche « aucune mesure » lorsque la liste est vide plutôt que lancer une moyenne invalide.
Un scénario complet utilise [12,14,13] et attend une moyenne de 13 secondes. Un second essaie une mesure -2 et vérifie le refus. On teste ensuite une séance sans mesure. Ces scénarios traversent les composants ; ils montrent que la conversion, les règles et l’affichage s’accordent. Une fois cette version utilisable, un graphique ou un import peuvent être ajoutés avec leurs propres critères, sans faire dépendre le service minimal de toutes les extensions imaginées.
Exemple suivi : arbitrer avec une estimation explicite
Dans l’atelier fictif, le socle demande douze heures : deux pour le besoin et le contrat, cinq pour le trajet minimal, trois pour les tests et l’intégration, deux pour la documentation et la démonstration. Avec seize heures disponibles, ajouter le graphique de trois heures laisse une heure de marge. Ajouter aussi un import de quatre heures porte la charge à dix-neuf heures et crée un dépassement de trois.
L’estimation n’est pas une promesse : un format de fichier inattendu ou une erreur peut déplacer la charge. La marge représente donc une capacité à absorber une incertitude, pas du temps automatiquement perdu. Pour arbitrer, comparez l’utilité de l’extension au scénario central et vérifiez ses dépendances. Retirer les tests pour conserver toutes les options donnerait une charge artificiellement acceptable en supprimant une partie de la réalisation attendue. Un point d’étape peut reporter une extension tout en livrant un socle expliqué et vérifié.
| Périmètre fictif | Charge | Marge avec 16 h |
|---|---|---|
| Socle | 12 h | 4 h |
| Socle et graphique | 15 h | 1 h |
| Socle, graphique et import | 19 h | -3 h |
À vous de faire varier les choses
Votre périmètre tient-il dans le temps disponible ?
Ce scénario fictif utilise des estimations pédagogiques, pas une promesse de durée réelle. Choisissez les extensions et observez ce qui reste pour valider et présenter.
Lire le résultat de l’expérience initiale
Marge restante : 1 heure(s).
Les tests, l’intégration et la présentation restent dans le socle. En cas de dépassement, examinez d’abord les extensions.
| Livrable | Estimation en heures | Cumul indicatif |
|---|---|---|
| Besoin et contrat | 2 | 0 → 2 |
| Trajet minimal : saisie, calcul, affichage | 5 | 2 → 7 |
| Graphique | 3 | 7 → 10 |
| Tests et intégration | 3 | 10 → 13 |
| Documentation et démonstration | 2 | 13 → 15 |
Le périmètre se choisit en conservant du temps pour vérifier et expliquer le service réalisé.
De la compréhension à l’autonomie
À vous de résoudre
Cherchez d’abord par vous-même. Vérifiez les résultats demandés, utilisez les indices si nécessaire, puis comparez votre méthode à la correction.
Réduire une idée trop large
Vous souhaitez créer « un réseau social complet ». Proposez une première réalisation locale suffisamment limitée pour être testée en NSI.
Indice 1
Choisissez un seul usage concret.
Indice 2
Évitez de rendre indispensables les comptes publics et l’hébergement pour commencer.
Comprendre la correction
Une première version peut afficher une liste de messages fictifs, permettre un filtrage par thème et enregistrer localement les données de démonstration. Elle possède déjà une acquisition, un traitement et une restitution vérifiables, tout en limitant les dépendances techniques.
Définir une interface
Un composant calcule la moyenne de temps de course. Son partenaire transmet des chaînes comme « 12 s ». Quelle convention faut-il fixer ?
Indice 1
Le calcul attend-il des nombres ou du texte ?
Indice 2
Les unités doivent être identiques.
Comprendre la correction
Il faut convenir d’une représentation, par exemple une liste de nombres exprimés en secondes, et décider où a lieu la validation ou conversion. Le calcul peut alors recevoir [12,13.5] plutôt que des textes mélangés. Les unités et le cas vide doivent être documentés.
Détecter une fausse fin
Chaque composant passe ses propres tests, mais aucun trajet complet n’a été essayé. Peut-on annoncer que le projet fonctionne de bout en bout ?
Indice 1
Les interfaces ont-elles été utilisées ensemble ?
Indice 2
Un défaut peut apparaître à la frontière de deux composants.
Comprendre la correction
Non. Il faut vérifier au moins un scénario complet représentatif. Deux composants peuvent être corrects selon des interprétations différentes des données. L’intégration teste ces échanges et les comportements combinés, en complément des tests isolés.
Arbitrer une extension
Il reste deux séances. L’importation et le calcul fonctionnent, mais aucune documentation ni démonstration n’est prête. Faut-il ajouter immédiatement une nouvelle visualisation complexe ?
Indice 1
Quels éléments permettent de vérifier et transmettre le travail existant ?
Indice 2
Une extension doit-elle empêcher la livraison du socle ?
Comprendre la correction
Il est plus pertinent de finaliser un scénario démontrable, les vérifications importantes et les instructions de lancement. L’extension peut être conservée comme perspective. Ce choix privilégie une réalisation expliquée et utilisable plutôt qu’un ensemble de possibilités inachevées.
Étude de cas : rendre un besoin testable
Une équipe propose une application de lecture « complète et jolie ». Reformulez un usage minimal pour suivre des livres fictifs, précisez deux champs et deux critères de réussite. Choisissez une extension à reporter. Donnez un exemple complet d’entrée et de sortie pour la première version.
Indice 1
Un utilisateur doit pouvoir réaliser une action identifiable.
Indice 2
Un critère comporte des données et un résultat observable.
Comprendre la correction
Un premier usage peut enregistrer des livres fictifs avec titre et état lu/non lu puis afficher les titres restant à lire. Avec A lu et B non lu, le filtre doit afficher B ; avec une liste vide, un message adapté apparaît. Une recommandation automatique peut être reportée. La première version rend déjà un service complet dont les champs et les résultats peuvent être testés.
Étude de cas : arbitrer un budget fictif
Le socle de l’atelier coûte 12 h. Le groupe dispose de 20 h et veut graphique (+3), import (+4) et export (+3), avec au moins 2 h de marge. Calculez la charge complète. Proposez un choix d’extensions compatible et expliquez ce qui déciderait entre deux choix possibles.
Indice 1
La charge maximale autorisée avec marge est 18 h.
Indice 2
Graphique plus export coûte six heures supplémentaires.
Comprendre la correction
Toutes les extensions donnent 22 h, soit un dépassement de deux et aucune marge. Graphique plus export donne 18 h et laisse deux heures. Import seul donne 16 h et laisse quatre heures. Le choix dépend du besoin central et des risques : si les données existent déjà en fichier, l’import peut être plus utile. Les tests, l’intégration et la documentation restent inclus dans chaque option.
Étude de cas : un assemblage incompatible
Le module de saisie produit ["12 s","14 s"] ; le module de calcul attend des nombres en minutes ; l’affichage écrit automatiquement « secondes ». Chaque auteur annonce que ses tests passent. Identifiez les incompatibilités, proposez un contrat commun et un scénario d’intégration. Qui doit pouvoir expliquer ce scénario ?
Indice 1
Type et unité sont deux problèmes distincts.
Indice 2
Choisissez une unité commune avant de convertir.
Comprendre la correction
Les chaînes doivent être converties et les unités harmonisées. Un contrat possible transmet [12,14] comme nombres en secondes ; le calcul renvoie 13, et l’affichage annonce 13 secondes. Un scénario saisit les deux temps et vérifie toute cette chaîne. Tous les membres doivent pouvoir expliquer les données échangées, même si un seul possède la responsabilité principale de chaque composant.
Les erreurs qui méritent un détour
- Répartir des tâches sans convenir des données échangées.
- Les composants risquent d’être incompatibles à l’intégration.
- Repousser tous les tests à la fin.
- Les erreurs de contrat deviennent plus coûteuses lorsque plusieurs composants en dépendent.
La fiche à garder
L’essentiel à retenir
- Un besoin concret guide le périmètre minimal.
- Les interfaces rendent le travail parallèle possible.
- Une intégration précoce et des points d’étape protègent la réalisation.
Le prochain pas
- Modules, bibliothèques, API et documentation
- Expliquer et justifier une solution à l’écrit et à l’oral
- Rechercher, vérifier et réutiliser des ressources et des données
Retrouver le catalogue des ressources
Ce chapitre s’appuie sur les programmes officiels de NSI (nouvel onglet). Les explications et exercices sont proposés pour l’apprentissage.