Développeur web back-end

Installer un poste de développement complet, adopter le flux de travail Git d'une équipe et transformer une demande client floue en un périmètre clair, découpé en tickets estimables.

Une coopérative de maraîchers de la région de Thiès veut vendre directement aux restaurants de Dakar, sans intermédiaire. Elle vous transmet un compte rendu d'entretien de deux pages, plein de souhaits et de contradictions. Votre mission : préparer le terrain du projet que vous développerez pendant tout le parcours. Vous installez votre environnement dans la stack choisie, créez le dépôt et définissez ses règles (branches, convention de commits, modèle de pull request). Vous rédigez ensuite une note de cadrage : acteurs, parcours principaux, ce qui est dans le périmètre de la première version et ce qui ne l'est pas. Vous découpez enfin ce périmètre en une vingtaine de tickets, chacun avec un critère d'acceptation. En soutenance, le mentor joue le client : il vous posera des questions sur vos arbitrages et vérifiera que chaque ticket est compréhensible par un autre développeur.

Maîtriser le langage de la stack choisie et modéliser les règles métier d'un domaine avec des classes, des interfaces et des responsabilités bien séparées, sans dépendre encore d'une base ni d'un framework web.

Avant d'exposer quoi que ce soit sur le web, la coopérative veut être sûre que ses règles de vente sont justes. Un restaurant commande des produits disponibles à une date de livraison ; chaque producteur fixe un prix au kilo et un minimum de commande ; les frais de livraison dépendent du quartier ; une commande peut être modifiée jusqu'à la veille à midi. Vous écrivez, dans le langage de votre stack, le cœur métier qui applique ces règles : produits, producteurs, commandes, calcul des montants, changements d'état. Le code doit rester indépendant de toute base de données et de tout framework web, pour être réutilisé aux sprints suivants. Un petit programme en ligne de commande permet de dérouler un scénario de bout en bout. Le mentor évaluera la lisibilité de vos classes, le nommage, la gestion des cas d'erreur et la facilité avec laquelle on peut ajouter une nouvelle règle.

Concevoir un schéma relationnel à partir des règles métier, l'implanter dans PostgreSQL par des migrations versionnées et relier le code métier à la base par la couche d'accès aux données de la stack.

Le moteur de commande fonctionne en mémoire ; il faut maintenant que les données survivent à un redémarrage. Vous concevez le schéma relationnel de la plateforme : producteurs, produits, disponibilités par date, restaurants, adresses de livraison, commandes et lignes de commande. Vous commencez par un modèle conceptuel, puis vous le traduisez en tables avec leurs clés, contraintes d'unicité et contraintes de vérification. Les tables sont créées par des migrations versionnées, jamais à la main. Vous branchez ensuite le module métier du sprint 2 sur la base grâce à la couche d'accès aux données de votre stack, et vous écrivez un jeu de données de démonstration réaliste. Pour finir, vous rédigez cinq requêtes SQL qui répondent aux questions de la coopérative, par exemple le chiffre d'affaires par producteur sur un mois ou les produits jamais commandés.

Exposer le domaine sous forme d'une API REST cohérente avec le framework de la stack : ressources bien nommées, codes HTTP justes, validation des entrées, pagination, erreurs uniformes et documentation OpenAPI.

Une agence partenaire va développer l'application mobile des restaurants. Elle attend une API stable et documentée, car elle travaillera sans vous parler tous les jours. Avec le framework de votre stack, vous exposez les ressources nécessaires : catalogue des produits disponibles à une date, consultation d'un producteur, création, modification et annulation d'une commande, historique des commandes d'un restaurant. Chaque entrée est validée, chaque erreur suit le même format, les listes sont paginées et filtrables. Les règles métier restent dans le module écrit au sprint 2 : les contrôleurs se contentent de les appeler. Vous publiez une documentation OpenAPI et une collection de requêtes prête à l'emploi. En soutenance, le mentor endossera le rôle de l'agence : il appellera votre API à partir de la seule documentation.

Protéger l'API : identifier les utilisateurs, limiter chacun à ses droits, se prémunir des principales failles du Top 10 OWASP et ne jamais exposer un secret.

La plateforme va s'ouvrir à trois types de comptes : les restaurants, les producteurs et l'équipe de la coopérative. Aujourd'hui, n'importe qui peut lire et modifier n'importe quelle commande. Vous mettez en place l'authentification avec des jetons d'accès de courte durée et un mécanisme de renouvellement, puis l'autorisation par rôle et par propriété : un restaurant ne voit que ses commandes, un producteur ne modifie que ses produits. Vous passez ensuite l'API au crible du Top 10 OWASP : injections, contrôle d'accès défaillant, exposition de données, limitation du nombre de tentatives. Les secrets sortent du code et passent par des variables d'environnement. Vous livrez une courte analyse de risques et la preuve que chaque faille identifiée est corrigée, sous forme de tests ou de requêtes rejouables.

Construire une stratégie de tests adaptée au service : tests unitaires du métier, tests d'intégration de l'API sur une vraie base, données de test maîtrisées et mesure de couverture utile.

La coopérative veut ajouter des remises pour les restaurants fidèles, mais personne n'ose toucher au calcul des montants depuis qu'une erreur de facturation a coûté une semaine de discussions. Vous construisez le filet de sécurité qui permettra d'évoluer sans crainte. Vous écrivez des tests unitaires pour toutes les règles métier, en particulier les cas limites (heure limite de modification, minimum de commande, quartier non desservi). Vous ajoutez des tests d'intégration qui appellent l'API sur une base de test isolée et remise à zéro entre deux exécutions. Une fois ce filet en place, vous implémentez la règle de remise en commençant par ses tests. Vous rédigez enfin une page qui explique votre stratégie : ce qui est testé, à quel niveau et pourquoi, et ce que la couverture mesurée ne garantit pas.

Rendre le service reproductible et livrable : image Docker légère, environnement local en une commande, pipeline qui teste et construit à chaque pull request, déploiement sur un serveur ou un service cloud.

L'agence mobile a besoin d'un environnement de recette accessible en permanence, et la coopérative veut voir la plateforme tourner avant la saison des récoltes. Vous conteneurisez l'API dans une image légère, sans secret embarqué, et vous décrivez l'environnement local complet (API et base) pour qu'un nouveau développeur le lance en une commande. Vous configurez un pipeline d'intégration continue qui, à chaque pull request, lance le linter, les tests du sprint 6 et la construction de l'image. Une fusion sur la branche principale déclenche le déploiement sur l'environnement de recette, migrations comprises. Vous ajoutez un point de santé, des journaux lisibles et une procédure de retour arrière documentée. En soutenance, vous déployez une modification en direct devant le mentor.

Mobiliser l'ensemble des compétences du parcours sur un besoin client réel issu d'une mission Formuloo, livrer un service en conditions professionnelles et le défendre devant un jury.

Ce dernier sprint vous place sur un besoin client réel issu d'une mission Formuloo : une API à créer ou un service existant à faire évoluer, par exemple pour une PME, une ONG ou une plateforme de commerce en ligne. Le sujet vous est remis au début du sprint avec ses contraintes réelles, anonymisées si nécessaire. Vous menez le projet comme en entreprise : reformulation du besoin, découpage en tickets, conception, développement dans la stack choisie, tests, déploiement en recette et documentation de passation. Le mentor joue le rôle de référent technique et un membre de l'équipe Formuloo celui du client. La soutenance finale se tient devant un jury. Vous présentez le service livré, puis votre portfolio des huit sprints, et vous répondez aux questions sur vos choix techniques, vos compromis et ce que vous feriez avec plus de temps.