Administrateur de base de données

Passer d'un besoin métier à un schéma relationnel solide : entités, associations, cardinalités, normalisation, clés et contraintes d'intégrité, en documentant chaque choix pour l'équipe de développement.

Sanaga Voyages relie Douala, Yaoundé, Bafoussam et Kribi plusieurs fois par jour. Sa billetterie actuelle est un tableur partagé entre les agences, avec des doublons et des places vendues deux fois. La compagnie sera votre cliente jusqu'au sprint 7. À partir des entretiens fournis, vous concevez la base de données de la nouvelle billetterie : lignes, arrêts, horaires, cars et leurs plans de sièges, voyages, réservations, billets, paiements, agences et guichetiers. Vous partez d'un modèle conceptuel, vous le normalisez, puis vous le traduisez en un schéma physique avec clés primaires et étrangères, contraintes d'unicité et de vérification. Une contrainte doit rendre impossible la vente d'un même siège deux fois sur un voyage. Vous livrez le script de création, un jeu de données réaliste et un dictionnaire de données.

Maîtriser le SQL dont un administrateur a besoin au quotidien : sous-requêtes, expressions de table communes, fonctions de fenêtrage, vues, procédures stockées, déclencheurs et transactions avec leurs niveaux d'isolation.

La direction de Sanaga Voyages veut piloter son activité et ses guichetiers se plaignent d'erreurs de saisie. Vous intervenez sur les deux fronts. Côté pilotage, vous écrivez les requêtes d'un tableau de bord : taux de remplissage par ligne et par jour, chiffre d'affaires par agence avec comparaison au mois précédent, classement des guichetiers, heures de pointe. Vous utilisez les expressions de table communes et les fonctions de fenêtrage, et vous exposez les résultats dans des vues. Côté gestion, vous écrivez une procédure de réservation qui vérifie la disponibilité du siège et enregistre billet et paiement dans une seule transaction, ainsi qu'un déclencheur qui trace toute annulation. En soutenance, le mentor lancera deux réservations simultanées du même siège pour vérifier votre gestion de la concurrence.

Installer le système de gestion de bases de données choisi sur un serveur Linux ou Windows, en comprendre l'architecture, régler ses paramètres essentiels et mettre en place une supervision de base.

La billetterie va passer en production. Sanaga Voyages a loué une machine virtuelle et vous demande d'y installer proprement le serveur de bases de données. Vous installez le système choisi à partir des paquets officiels, en séparant fichiers de données, journaux de transactions et sauvegardes. Vous réglez les paramètres essentiels en fonction de la mémoire et des processeurs disponibles (mémoire partagée, connexions, journalisation) et vous justifiez chaque valeur. Vous configurez l'accès réseau pour que seuls les serveurs applicatifs puissent se connecter. Vous déployez le schéma du sprint 1 et mettez en place une supervision minimale : espace disque, connexions actives, requêtes longues, erreurs dans les journaux. Vous rédigez une procédure d'installation assez précise pour qu'un collègue reproduise le serveur à l'identique.

Protéger la base : modèle de rôles fondé sur le moindre privilège, séparation des comptes applicatifs et humains, chiffrement des connexions et des données sensibles, audit des accès et conformité aux règles de protection des données.

Un audit interne a révélé que l'application, les guichetiers et le comptable utilisent tous le même compte administrateur. Les numéros de téléphone et les pièces d'identité des voyageurs sont lisibles par tous. Vous concevez un modèle de rôles : compte de l'application avec les seuls droits nécessaires, rôle de lecture pour le reporting, rôle de comptabilité limité aux paiements, comptes nominatifs pour les administrateurs. Vous retirez les droits superflus, activez le chiffrement des connexions et protégez les données personnelles sensibles (chiffrement ou masquage selon le système). Vous mettez en place l'audit des connexions et des opérations sensibles, et vous définissez une politique de rotation des mots de passe des comptes techniques. Votre matrice des droits doit permettre de répondre en une minute à la question « qui peut lire les pièces d'identité ? ».

Garantir que les données survivent à toute panne : politique de sauvegarde alignée sur les objectifs de perte et de durée d'interruption, restauration à un instant précis, tests réguliers et plan de reprise d'activité documenté.

Une agence voisine a perdu trois jours de ventes après une panne de disque : ses sauvegardes n'avaient jamais été testées. La direction de Sanaga Voyages vous demande de garantir qu'au pire, elle ne perdra que quelques minutes de réservations. Avec la direction, vous fixez la perte de données maximale acceptable et la durée d'interruption tolérable. Vous en déduisez une politique : sauvegardes complètes, archivage continu des journaux de transactions, rétention, copie hors site chiffrée. Vous automatisez le tout et vous ajoutez une alerte en cas d'échec. Vous réalisez ensuite trois exercices chronométrés : restauration complète sur un serveur vierge, restauration à l'instant précédant une suppression accidentelle, reprise après perte du serveur. Le plan de reprise doit pouvoir être suivi par une personne d'astreinte à trois heures du matin.

Diagnostiquer et résoudre des problèmes de performance : repérer les requêtes coûteuses, lire un plan d'exécution, choisir les bons index, maintenir les statistiques et régler le serveur sous une charge réaliste.

Chaque année, la semaine précédant les fêtes, les ventes sont multipliées par dix et la billetterie devient très lente. Vous disposez d'un jeu de données de trois ans d'historique et d'un scénario de charge qui simule ces pics. Vous lancez la charge, puis vous identifiez les requêtes les plus coûteuses grâce aux outils de votre système. Pour chacune, vous lisez le plan d'exécution, vous expliquez le problème (parcours complet de table, mauvaise estimation, verrou) et vous proposez une correction : index adapté, réécriture de la requête, mise à jour des statistiques, partitionnement de l'historique. Vous vérifiez aussi l'effet de vos index sur les écritures. Vous terminez par un réglage du serveur et une seconde mesure. Le rapport compare les temps de réponse avant et après sous la même charge.

Rendre la base résistante aux pannes et comparer les options : réplication, bascule automatique ou manuelle, réplicas en lecture, base managée chez un fournisseur cloud, et premières notions de NoSQL pour savoir quand y recourir.

Sanaga Voyages ouvre la vente en ligne la nuit et ne peut plus se permettre d'arrêt. Elle hésite entre garder ses serveurs et passer à une base managée chez un fournisseur cloud. Vous mettez en place une réplication entre un serveur principal et un serveur secondaire, avec un réplica en lecture pour le reporting. Vous simulez la panne du serveur principal, vous effectuez la bascule et vous mesurez la durée d'interruption et les données éventuellement perdues. Vous déployez ensuite la même base sur un service managé (RDS ou son équivalent pour votre système) et vous comparez les deux options : coût, effort d'exploitation, sauvegardes, contrôle. Pour finir, vous indiquez si une base NoSQL serait utile pour un besoin précis de la compagnie, comme le suivi des cars en temps réel. Votre note de recommandation s'adresse à la direction, pas aux techniciens.

Prendre en charge une base de production réelle issue d'une mission Formuloo : audit, plan de migration, exécution en limitant l'interruption, vérification des données, puis soutenance finale devant un jury.

Ce dernier sprint vous confie une base de production réelle issue d'une mission Formuloo, par exemple celle d'une PME, d'une ONG ou d'une plateforme de commerce en ligne, à faire migrer vers une nouvelle version du système, un nouveau serveur ou une base managée. Les données personnelles sont anonymisées avant de vous être remises. Vous commencez par un audit : schéma, volumétrie, droits, sauvegardes, requêtes lentes, risques. Vous rédigez un plan de migration avec ses étapes, sa répétition à blanc, sa durée d'interruption prévue, ses contrôles de cohérence et son plan de retour arrière. Vous exécutez la migration en conditions réelles, puis vous vérifiez les données et les performances. Le mentor joue le référent technique et un membre de l'équipe Formuloo le client. La soutenance finale, devant un jury, porte sur cette mission et sur votre portfolio des huit sprints.