Apprentissages Critiques
AC13.01AC13.02AC13.03AC13.04AC13.05AC13.06
Ce que j'ai fait
Lors des SAÉ 1.04 et 1.05, j'ai utilisé un environnement de développement complet : éditeur VS Code, terminal Linux/Bash, Git pour le versionnement, et un serveur web pour héberger mes réalisations (GitHub Pages pour le portfolio, public_html pour le traitement de données).
Pourquoi je l'ai fait
L'objectif était de maîtriser les outils de base d'un service informatique afin de pouvoir développer, tester et déployer mes projets de façon autonome.
Comment je l'ai fait
J'ai travaillé sous Linux avec des scripts Bash, utilisé VS Code pour coder, configuré les proxies de l'université (cache-etu.univ-artois.fr) et déployé via Git (add / commit / push) sur GitHub.
Mes difficultés
La configuration de l'environnement (proxies, droits sur les fichiers avec chmod, chemins) a été source d'erreurs au début, notamment pour que les scripts s'exécutent correctement.
Ce que j'en ai appris
J'ai gagné en autonomie sur les outils fondamentaux : ligne de commande, gestion des fichiers et permissions, versionnement Git. Ces outils sont devenus naturels au fil des SAÉ.
Ce que je ferais autrement
J'organiserais mieux mes dépôts dès le départ (structure de dossiers claire, commits plus fréquents et mieux nommés) pour faciliter le suivi et la collaboration.
Ce que j'ai fait
Dans la SAÉ 1.05, j'ai écrit, exécuté et débogué une chaîne complète de traitement de données : un script Bash de téléchargement/nettoyage et un script Python de conversion CSV→JSON, avec gestion des erreurs (validation des données, KeyError).
Pourquoi je l'ai fait
L'objectif était d'être capable non seulement d'écrire du code, mais aussi de le faire fonctionner, d'identifier les erreurs et de les corriger jusqu'à obtenir un résultat fiable.
Comment je l'ai fait
J'ai utilisé Python (module csv, json) et Bash (wget, unzip, cut, grep, sort), testé chaque étape progressivement, et ajouté des affichages de débogage (print des colonnes trouvées) pour vérifier le bon déroulement.
Mes difficultés
La gestion des cas particuliers (valeurs non numériques, colonnes manquantes, encodage des fichiers avec caractères spéciaux) a généré plusieurs erreurs qu'il a fallu corriger une à une. L'affichage du graphique à partir du fichier JSON a été le plus délicat ; j'ai surmonté le problème en consultant la documentation officielle de CanvasJS et des tutoriels vidéo.
Ce que j'en ai appris
J'ai appris l'importance de la validation des données et de la gestion des erreurs (try/except) pour qu'un programme reste robuste face à des entrées imparfaites, ce qui est très fréquent avec des données réelles.
Ce que je ferais autrement
J'ajouterais des tests automatiques et une gestion d'erreurs plus systématique dès l'écriture du code, plutôt que de corriger les bugs au fur et à mesure qu'ils apparaissent.
Ce que j'ai fait
Dans la SAÉ 1.05, j'ai traduit un même besoin (traiter des données ouvertes sur les produits pétroliers) en plusieurs langages selon l'étape : Bash pour l'acquisition et le pré-traitement, Python pour la transformation CSV→JSON, et JavaScript/PHP pour la visualisation web.
Pourquoi je l'ai fait
L'objectif était de choisir le bon langage pour chaque tâche et de traduire un algorithme abstrait (récupérer → trier → convertir → afficher) dans l'environnement le plus adapté.
Comment je l'ai fait
J'ai utilisé Bash pour sa puissance en manipulation de fichiers (cut, grep, sort), Python pour sa simplicité de traitement de données structurées, et CanvasJS/jQuery pour le rendu graphique côté web.
Mes difficultés
Passer d'un langage à l'autre tout en gardant une logique cohérente sur l'ensemble de la chaîne demandait de bien comprendre les forces de chacun et d'assurer la compatibilité des formats entre les étapes (CSV puis JSON).
Ce que j'en ai appris
J'ai compris qu'il n'existe pas de langage universel : chaque outil a son domaine de prédilection, et savoir les combiner est une compétence à part entière.
Ce que je ferais autrement
Je documenterais davantage le passage de données entre les étapes (format attendu en entrée/sortie de chaque script) pour rendre la chaîne plus claire et maintenable.
Ce que j'ai fait
Dans la SAÉ 1.04, j'ai conçu ce portfolio web personnel : un site responsive multi-pages en HTML/CSS pur, avec une page d'accueil, une présentation, un parcours, un tableau de compétences interactif renvoyant vers une page détaillée par niveau, et un menu de navigation. J'ai aussi réalisé en SAÉ 1.05 la partie web d'affichage des données : une page PHP/HTML qui lit le fichier JSON et en génère un graphique interactif avec la bibliothèque CanvasJS.
Pourquoi je l'ai fait
L'objectif était de me présenter sur Internet en maîtrisant les technologies du Web (structure HTML, mise en forme CSS, responsive design) et de respecter les recommandations W3C.
Comment je l'ai fait
J'ai structuré le HTML sémantiquement, séparé le CSS dans un fichier dédié, rendu le site responsive (3 affichages : mobile, tablette, desktop) avec des media queries et un menu hamburger, utilisé des chemins relatifs, et hébergé le tout sur GitHub Pages.
Mes difficultés
Rendre le site parfaitement responsive sur tous les écrans (notamment la section parcours en deux colonnes et le tableau de compétences) a demandé plusieurs ajustements. Gérer la couleur par défaut des liens et les états de survol a aussi nécessité du soin.
Ce que j'en ai appris
J'ai consolidé ma maîtrise du HTML/CSS, compris l'intérêt de séparer structure et style, et appris à concevoir une interface adaptative et cohérente. J'ai aussi découvert l'hébergement statique via GitHub Pages.
Ce que je ferais autrement
Le sujet proposait de partir d'un template Bootstrap ; j'ai préféré construire le site entièrement à la main pour mieux comprendre chaque ligne. Avec plus de recul, j'intégrerais un framework léger pour gagner du temps tout en gardant le contrôle du rendu.
Ce que j'ai fait
Dans la SAÉ 1.05, j'ai choisi et justifié les formats de données de la chaîne de traitement : extraction depuis un CSV (données brutes data.gouv.fr), transformation en JSON (format adapté à l'échange et à la lecture par le web), puis affichage via CanvasJS.
Pourquoi je l'ai fait
L'objectif était de sélectionner les formats les plus pertinents à chaque étape selon l'usage : stockage/manipulation tabulaire (CSV) versus échange avec une page web (JSON).
Comment je l'ai fait
J'ai utilisé le module csv de Python avec DictReader (séparateur point-virgule) pour lire les données, puis json.dump pour produire un fichier structuré et indenté, exploité ensuite côté client par jQuery ($.getJSON).
Mes difficultés
Comprendre pourquoi convertir le CSV en JSON plutôt que de l'exploiter directement n'était pas évident au départ ; c'est en intégrant l'affichage web que la pertinence du JSON est devenue claire.
Ce que j'en ai appris
J'ai appris à raisonner sur le format de données en fonction de sa destination, et compris que le JSON est le format de référence pour échanger des données avec une application web.
Ce que je ferais autrement
Pour un volume de données plus important ou des requêtes plus complexes, j'opterais pour une vraie base de données (comme je l'ai fait ensuite en SAÉ 2.03 avec PostgreSQL) plutôt que de simples fichiers.
Ce que j'ai fait
Les SAÉ 1.04 et 1.05 ont été menées en utilisant Git/GitHub pour le versionnement et le déploiement, et la SAÉ 1.05 a été réalisée en équipe (Thomas, Aurélien, Estéban) avec une répartition des tâches formalisée par un diagramme de Gantt.
Pourquoi je l'ai fait
L'objectif était d'apprendre à travailler dans un environnement de développement collaboratif moderne, avec gestion de versions et coordination d'équipe.
Comment je l'ai fait
Nous avons réparti les tâches via un Gantt (recherche, code en trois parties, tests, diaporama), utilisé Git pour versionner le code, et GitHub pour héberger et partager. La communication d'équipe assurait la cohérence de l'ensemble.
Mes difficultés
Coordonner le travail de plusieurs personnes sur un même projet et fusionner les différentes parties du code sans conflit a demandé de la rigueur et de la communication.
Ce que j'en ai appris
J'ai appris à utiliser Git dans un contexte d'équipe et compris l'importance d'une bonne répartition des tâches et d'une communication régulière pour mener un projet collectif à terme.
Ce que je ferais autrement
J'utiliserais davantage les branches Git et les pull requests pour mieux isoler le travail de chacun et faciliter la relecture, plutôt que de tout fusionner manuellement à la fin.