Dans la SAÉ 2.03, j'ai automatisé le déploiement complet de l'application web grâce à Docker et Docker Compose : un simple « docker-compose up » lance et configure automatiquement les deux services (application Flask + base PostgreSQL). En SAÉ 1.05 j'avais aussi automatisé tout un traitement de données via un script Bash.

L'objectif était d'automatiser des tâches répétitives (déploiement, configuration, attente de disponibilité de la base) pour gagner en fiabilité et en reproductibilité, au lieu de les faire manuellement.

J'ai écrit un Dockerfile (image Python 3.11-slim, installation des dépendances) et un docker-compose.yml orchestrant les services avec leurs variables d'environnement, volumes et dépendances. J'ai aussi codé une boucle d'attente (psycopg2) pour que l'app patiente jusqu'à ce que PostgreSQL soit prêt.

La synchronisation entre les conteneurs a posé problème : l'application Flask démarrait avant que PostgreSQL ne soit prêt, ce qui provoquait des erreurs de connexion. Il a fallu implémenter un mécanisme d'attente.

J'ai appris la conteneurisation et l'orchestration multi-services, et compris l'intérêt énorme de l'automatisation : un environnement reproductible à l'identique sur n'importe quelle machine, sans configuration manuelle.

J'utiliserais les healthchecks de Docker Compose plutôt qu'une boucle d'attente codée à la main, qui est une solution de contournement moins propre.

Dans la SAÉ 2.03, j'ai développé avec mon binôme une application web Flask de gestion de compétences (authentification, pages protégées, CRUD). Dans la SAÉ 3.02, j'ai développé un moteur de recherche de documents en Python répondant à un cahier des charges précis (recherche multi-formats, opérateurs logiques, interface graphique).

L'objectif était de concevoir des applications complètes répondant à des besoins fonctionnels définis, de l'interface jusqu'au traitement des données.

Pour le moteur de recherche, j'ai structuré le projet en modules (moteur de recherche, serveur, client GUI) et implémenté les fonctionnalités demandées : recherche dans des fichiers TXT, HTML, PDF et Excel (avec BeautifulSoup, pypdf et openpyxl), recherche par mot-clé, opérateurs booléens AND/OR et mode expression régulière, en restituant pour chaque résultat le fichier, la localisation (ligne, page ou cellule) et un extrait de contexte.

Couvrir proprement tous les formats de fichiers demandés (chaque format a sa logique d'extraction) et implémenter les trois modes de recherche (simple, booléen, regex) de façon cohérente a été la partie la plus exigeante.

J'ai appris à traduire un cahier des charges en une application modulaire et à intégrer des bibliothèques tierces pour traiter des formats de données hétérogènes.

J'ajouterais une indexation préalable des documents (au lieu de les relire à chaque requête) pour améliorer les performances sur de grands volumes.

Dans la SAÉ 3.02, j'ai développé en Python un moteur de recherche de documents en architecture client/serveur communiquant directement via le protocole TCP (sockets), avec un serveur multi-clients et un client graphique.

L'objectif était de programmer une application réseau de bout en bout en maîtrisant la communication bas niveau entre client et serveur, sans passer par un framework web.

J'ai écrit un serveur TCP avec le module socket (écoute sur 127.0.0.1:65432, SO_REUSEADDR) qui crée un thread par client pour gérer plusieurs connexions simultanées ; le client envoie sa requête, le serveur lance la recherche et renvoie les résultats sérialisés en JSON via sendall. Le client graphique (Tkinter) construit la requête, l'envoie sur le socket et affiche les résultats reçus.

Gérer la communication par socket (découpage des messages, encodage/décodage UTF-8, sérialisation JSON des résultats) et le multi-clients par threads sans bloquer le serveur a demandé de bien comprendre le fonctionnement de TCP.

J'ai appris à programmer une application communicante directement au-dessus de TCP, à définir un échange requête/réponse structuré (JSON) et à gérer la concurrence côté serveur avec des threads.

Je définirais un protocole applicatif plus robuste (préfixe de longueur ou délimiteur de message pour gérer les gros résultats) et j'ajouterais une gestion d'erreurs réseau plus complète côté client.

Dans la SAÉ 2.03, j'ai mis en place et administré une base de données PostgreSQL 15 conteneurisée : création des tables (User, Competence), gestion des séquences et clés primaires, contraintes d'unicité, le tout documenté dans un script SQL (db.sql).

L'objectif était d'apprendre à installer, configurer et administrer un véritable SGBD relationnel pour la persistance des données d'une application.

J'ai déployé PostgreSQL via Docker (image officielle, variables d'environnement pour l'utilisateur/mot de passe/base), défini le schéma via SQLAlchemy et le script SQL, et géré la connexion avec psycopg2.

La connexion entre l'application et la base dans l'environnement conteneurisé (gestion de l'hôte « db », des identifiants, du timing de démarrage) a été la principale difficulté.

J'ai appris à administrer un SGBD relationnel, à concevoir un schéma de base (tables, clés, contraintes) et à connecter une base à une application. C'est une compétence directement transposable en milieu professionnel.

Je mettrais en place des sauvegardes automatiques de la base et une gestion plus fine des migrations de schéma (avec un outil dédié) pour un usage plus proche de la production.

L'application Flask de la SAÉ 2.03 accède aux données de la base PostgreSQL via l'ORM SQLAlchemy : lecture des compétences pour les afficher (Competence.query.all()), ajout et suppression d'enregistrements, et vérification des utilisateurs lors de la connexion. En SAÉ 1.05, j'avais accédé à des données depuis une page web via JSON et jQuery.

L'objectif était de relier l'interface (le site web) aux données stockées, pour que l'application soit réellement dynamique et persistante.

J'ai utilisé l'ORM SQLAlchemy pour manipuler la base sans écrire de SQL brut (requêtes via objets Python), et côté SAÉ 1.05 j'avais utilisé $.getJSON pour charger dynamiquement des données JSON dans un graphique.

Comprendre le fonctionnement de l'ORM (correspondance objets Python ↔ tables SQL) et gérer les sessions de base de données (commit, rollback) a demandé un temps d'adaptation.

J'ai appris deux approches d'accès aux données : l'ORM côté serveur (SQLAlchemy) et le chargement asynchrone côté client (JSON/jQuery), et compris quand utiliser l'une ou l'autre.

Je sécuriserais et optimiserais davantage les requêtes (pagination pour de gros volumes, gestion fine des erreurs de base) pour une application destinée à passer à l'échelle.