Un cap pour ce chapitre
Ce que vous saurez faire
- Identifier provenance, contexte et limites d’une ressource.
- Contrôler une donnée et tester un code emprunté.
- Documenter les références et conditions de réutilisation.
Les bases utiles pour commencer
Partir de la question à vérifier
Formulez une question précise : « Cette fonction modifie-t-elle la liste ? » appelle la documentation de son API et un test ciblé. « Quelle épreuve s’applique à cette session ? » appelle un texte officiel daté. Une page très bien présentée peut ne pas être la source adaptée au fait recherché.
Repérez l’auteur ou l’organisme, la date, les références citées et le contexte. Pour un comportement technique, privilégiez la documentation du projet ou une expérience reproductible. Pour une règle scolaire, consultez la source institutionnelle pertinente. Une réponse produite par une IA peut aider à formuler des pistes, mais ses affirmations et références doivent être vérifiées comme celles d’une autre source.
Une bonne référence permet de retrouver la phrase ou le tableau utile. Conservez le titre précis et le lien vers le document, plutôt que seulement le nom d’un moteur de recherche. Si deux sources se répètent sans expliquer leur origine, elles ne constituent pas nécessairement deux confirmations indépendantes.
Lire les données avec leurs unités et leur périmètre
Un tableau « temps moyen : 12 » reste inutilisable sans unité, population et méthode de mesure. Douze secondes n’est pas douze minutes ; une moyenne sur dix participants ne décrit pas nécessairement tous les élèves. Vérifiez aussi les valeurs manquantes, les doublons et les changements de définition entre fichiers.
Une hausse de vingt pour cent après une baisse de vingt pour cent ne ramène pas au point initial, car les bases de calcul diffèrent. Les transformations et filtres doivent être décrits pour que quelqu’un puisse reproduire le résultat. Conserver les données sources séparément de la version nettoyée facilite ce contrôle.
Réutiliser en comprenant et en attribuant
Un extrait de programme trouvé en ligne doit être lu, testé et adapté à un contrat identifié. Vérifiez les entrées autorisées, les effets de bord, les dépendances et les cas limites. Un résultat correct sur la démonstration publiée ne prouve pas son adéquation à votre projet.
Consultez les conditions ou la licence de la ressource avant de la redistribuer. Citer l’auteur et le lien permet de reconnaître la provenance, mais ne remplace pas les conditions de réutilisation. Si elles ne sont pas claires, choisissez une autre ressource explicitement réutilisable ou demandez les informations nécessaires. Conservez une note des références utilisées dans le projet.
Limiter les informations personnelles et rendre le travail traçable
Pour tester une application scolaire, des données fictives suffisent souvent : noms inventés, mesures simulées et identifiants sans lien avec de vraies personnes. Avant de publier un fichier, examinez ses colonnes, ses métadonnées et ses commentaires. Une information peut permettre de reconnaître quelqu’un même si son nom a été supprimé.
Un dossier de projet peut conserver le lien de source, sa date de consultation, la version utilisée, les modifications apportées et les limites connues. Cette traçabilité aide à corriger une erreur et à expliquer les résultats. L’usage responsable de l’informatique consiste aussi à mesurer ce qui est nécessaire à la tâche, plutôt qu’à collecter ou diffuser tout ce qui est disponible.
Exemple suivi : comparer des moyennes compatibles
Deux tableaux fictifs annoncent un temps moyen de 12 et de 0,25. Le premier utilise les secondes, le second les minutes. Après conversion, 0,25 minute vaut 15 secondes : comparer directement 12 à 0,25 aurait inversé l’interprétation. Il faut encore vérifier ce qui est mesuré, la période, le nombre de participants et le traitement des absences avant d’attribuer l’écart à une performance.
Une autre difficulté apparaît avec des groupes de tailles différentes. Deux élèves ont une moyenne de 10 et huit élèves une moyenne de 15. La moyenne des dix élèves vaut (2×10+8×15)/10=14, et non (10+15)/2=12,5. Un tableau de travail doit donc conserver les effectifs qui servent de poids. La justesse de chaque moyenne de groupe ne garantit pas la justesse d’une combinaison qui oublie sa population.
| Groupe fictif | Effectif | Moyenne en secondes | Somme des temps |
|---|---|---|---|
| Premier | 2 | 10 | 20 |
| Second | 8 | 15 | 120 |
| Ensemble | 10 | 14 | 140 |
Exemple suivi : réutiliser un extrait sans perdre son contrat
Une fonction trouvée dans une ressource trie une liste sur place puis renvoie None. Votre projet souhaite une nouvelle liste triée tout en conservant l’original. Le résultat visuel d’une démonstration peut sembler convenir, mais le contrat diffère. Avant l’intégration, préparez une entrée [3,1,2], prévoyez le résultat trié [1,2,3] et vérifiez que l’entrée reste [3,1,2]. Si elle change, la fonction doit être adaptée ou remplacée conformément au besoin.
La note de réutilisation peut indiquer la provenance, la version, les conditions de diffusion annoncées, la modification apportée et les tests réalisés. Attribuer l’auteur ne prouve pas l’autorisation de redistribuer ; réussir un test ne prouve pas tous les cas ; recopier un commentaire ne garantit pas son exactitude. Chaque élément répond à une question différente. Pour la démonstration publique, remplacez les données personnelles inutiles par des jeux fictifs qui conservent les frontières et défauts que vous souhaitez tester.
À vous de faire varier les choses
Que faut-il vérifier en priorité ?
Ces situations sont fictives. Choisissez la vérification prioritaire pour chacune ; le retour explique le risque de mauvaise conclusion.
Lire les associations expliquées
- Une page décrit une épreuve mais ne précise pas la session concernée. : Source et version
- Il faut retrouver le texte applicable et sa date.
- Un CSV indique durée=12 sans unité. : Unités et contexte
- Le nombre n’a pas de sens exploitable sans son unité.
- Une fonction copiée réussit sur trois valeurs mais échoue sur une liste vide. : Contrat et tests
- Le domaine et les cas limites doivent correspondre à votre besoin.
- Une illustration est trouvée sans licence ou conditions visibles. : Conditions de réutilisation
- La disponibilité sur le Web ne décrit pas ses usages autorisés.
- Un fichier de démonstration contient noms, classes et horaires réels. : Informations personnelles
- La démonstration peut souvent utiliser des données fictives.
- La moyenne annoncée concerne seulement les cinq premiers répondants. : Unités et contexte
- Le périmètre limite la portée du résultat.
- Une documentation correspond à une autre version de la bibliothèque. : Source et version
- Il faut vérifier le contrat de la version réellement utilisée.
- Un module modifie silencieusement la liste reçue. : Contrat et tests
- Cet effet de bord doit être connu et compatible avec le programme appelant.
- Le nom a été supprimé, mais une combinaison de détails identifie une personne. : Informations personnelles
- L’identification peut reposer sur plusieurs champs combinés.
- Deux moyennes sont 12 secondes et 0,25 minute ; un graphique compare directement 12 à 0,25. : Unités et contexte
- La conversion donne 15 secondes pour la seconde mesure. Il faut harmoniser les unités avant de comparer.
- Un résultat provient d’une fonction qui trie l’entrée sur place alors que le projet doit conserver cette entrée. : Contrat et tests
- La démonstration peut donner la bonne séquence et violer l’absence de mutation. Testez les deux objets.
- Trois articles répètent un même chiffre sans citer son origine et une archive originale est disponible. : Source et version
- La répétition n’établit pas trois confirmations indépendantes. Retrouvez le document qui définit la mesure et son contexte.
Vérifier consiste à identifier ce qui manque pour conclure correctement, puis à chercher une preuve adaptée.
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.
Choisir une source adaptée
Vous voulez savoir si une fonction d’une bibliothèque modifie la liste reçue. Entre un commentaire anonyme et la documentation de la version utilisée, où commencer ?
Indice 1
Cherchez le contrat de l’API.
Indice 2
La version peut changer le comportement ou l’interface.
Comprendre la correction
Commencez par la documentation de la version utilisée, puis construisez un test ciblé si nécessaire. Le commentaire peut signaler une piste, mais ne remplace pas le contrat identifiable. Notez aussi les conditions dans lesquelles l’observation est réalisée.
Vérifier une transformation
Une quantité vaut cent, baisse de vingt pour cent puis augmente de vingt pour cent. Revient-elle à cent ?
Indice 1
La première transformation donne quatre-vingts.
Indice 2
La seconde augmentation porte sur cette nouvelle base.
Comprendre la correction
Non. Cent devient quatre-vingts, puis quatre-vingts multiplié par 1,2 donne quatre-vingt-seize. Les deux pourcentages n’ont pas la même base. Une explication de données doit préciser ce contexte pour éviter une conclusion trompeuse.
Distinguer citation et permission
Vous trouvez une image sans conditions de réutilisation visibles. Ajouter le nom de l’auteur suffit-il à connaître ce que vous pouvez en faire ?
Indice 1
La provenance et les conditions sont deux informations différentes.
Indice 2
Une absence d’information ne définit pas une autorisation.
Comprendre la correction
Non. La citation indique la provenance, mais ne précise pas les usages autorisés. Il faut rechercher les conditions applicables ou choisir une ressource dont la réutilisation est clairement définie. Pour un projet, créer un schéma original est aussi une possibilité.
Préparer une publication de données
Un fichier d’essai contient les vrais prénoms, classes et horaires d’élèves. Le projet nécessite-t-il ces informations pour montrer un calcul de moyenne ?
Indice 1
Le mécanisme dépend-il de l’identité ?
Indice 2
Des données fictives peuvent conserver les cas de test.
Comprendre la correction
Non, le calcul peut être démontré avec des identifiants et mesures fictifs. Cela permet de conserver valeurs normales, limites et manquantes sans diffuser des informations sur les élèves. Il faut aussi vérifier les commentaires et fichiers annexes avant de publier le projet.
Étude de cas : contrôler une moyenne publiée
Deux groupes fictifs comptent respectivement deux et huit participants. Leurs temps moyens sont 10 et 15 secondes. Un compte rendu annonce une moyenne globale de 12,5 secondes. Vérifiez le calcul, expliquez l’erreur et listez deux autres informations nécessaires avant de comparer ces données à une autre étude.
Indice 1
La moyenne globale pondère chaque groupe par son effectif.
Indice 2
Des unités communes ne garantissent pas une population ou une mesure identique.
Comprendre la correction
La somme des temps vaut 2×10+8×15=140 secondes pour dix participants, donc la moyenne est 14 secondes. 12,5 donnerait le même poids à des groupes de tailles différentes. Il faut aussi vérifier le protocole de mesure, la période, le profil des participants et le traitement des valeurs manquantes avant une comparaison. L’erreur vient de l’agrégation, pas forcément des moyennes sources.
Étude de cas : confronter un code au besoin
Un extrait documenté comme « trie sur place et renvoie None » est utilisé par resultat = trier(notes). Le projet doit conserver notes et afficher une nouvelle liste. Identifiez les deux incompatibilités, proposez une intégration possible et préparez les tests sur [3,1,2], une liste vide et des doublons.
Indice 1
Le retour et la mutation sont deux propriétés distinctes.
Indice 2
On peut faire porter la mutation sur une copie autorisée.
Comprendre la correction
resultat reçoit None et notes est modifiée. Une intégration possible copie notes dans resultat puis trie cette copie sur place, si les conditions de réutilisation et le contrat le permettent. Les sorties attendues sont [1,2,3], [] et, pour [2,2,1], [1,2,2]. Dans les trois cas, l’original doit rester identique. On note l’adaptation et sa provenance pour pouvoir la vérifier ensuite.
Étude de cas : préparer un dossier partageable
Un projet de moyenne contient un CSV avec prénoms, classes et horaires réels, une image sans conditions identifiées et un fichier de calcul adapté d’une documentation. Préparez les décisions de publication et une note de provenance. Quels éléments peuvent être remplacés sans changer la démonstration du calcul ?
Indice 1
Le calcul n’a pas besoin de l’identité des personnes.
Indice 2
Source, droit de réutilisation et validation technique doivent être distingués.
Comprendre la correction
Remplacez les mesures et identifiants par un jeu fictif qui conserve les cas utiles, puis examinez aussi les fichiers annexes. Pour l’image, recherchez les conditions ou choisissez un schéma original ou une ressource clairement réutilisable. La note du code indique source, version, adaptation et tests. Ces décisions préservent la démonstration sans supposer que citer une source règle toutes les autres questions.
Les erreurs qui méritent un détour
- Confondre popularité d’une page et fiabilité d’une affirmation.
- La provenance, les preuves et le contexte portent la vérification.
- Supposer qu’un code copié est adapté parce qu’il s’exécute.
- Il doit respecter votre contrat, vos données et les conditions de réutilisation.
La fiche à garder
L’essentiel à retenir
- La bonne source dépend de la question posée.
- Une donnée doit être lue avec ses unités, sa population et sa méthode.
- Provenance, tests et conditions de réutilisation doivent rester traçables.
Le prochain pas
- Concevoir et mener un projet de NSI
- Histoire de l’informatique : évolution du matériel et du logiciel
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.