Coordonner les repas, de la préparation à la livraison

Le besoin métier

Une activité traiteur qui prépare des repas sur plusieurs semaines doit coordonner les personnes présentes, les menus et les quantités. Une journée peut avoir un responsable de production et des renforts ; le nombre de convives change ; une personne se désiste ; le plat ou le dessert doivent être connus assez tôt pour acheter et préparer. Un tableur partagé permet de voir un calendrier, mais gère mal les réservations simultanées et les conséquences d'une annulation.

Le besoin décrit dans le dossier source porte sur une fenêtre de cinq semaines, soit vingt-cinq jours de service, avec jusqu'à trois personnes affectées par jour : un coordinateur et deux appuis. Le coordinateur choisit le plat et le dessert dans un catalogue. L'équipe doit obtenir une liste de production et d'ingrédients cohérente avec l'effectif prévu, ainsi que des rappels avant le service. Il fallait rendre ces règles compréhensibles dans un outil web, tout en gardant les décisions de menu et de sécurité alimentaire aux personnes responsables.

La solution et son périmètre

L'application réunit un planning, des comptes utilisateurs, des rôles et un catalogue de recettes. Un participant réserve une place disponible ; le premier rôle de coordination et les places d'appui sont suivis séparément. La personne qui coordonne choisit le plat principal et le dessert. Une proposition hors catalogue demande une validation administrative avant de devenir un menu utilisable.

Pour chaque semaine, l'administration peut renseigner le nombre de convives et les détails logistiques utiles à la livraison. Les recettes enregistrées fournissent des ingrédients de référence par personne et des liens de préparation. Les documents PDF et XLSX donnent une vue du planning, des menus et des quantités calculées. Le système prépare l'organisation ; il ne constitue pas un ERP traiteur couvrant devis commerciaux, stocks, allergènes, traçabilité sanitaire ou chaîne du froid.

De la réservation au service

1. L'administration ouvre les jours de service de la période et renseigne les paramètres de la semaine.
2. Une personne choisit un jour libre ; la réservation est confirmée seulement si le rôle et la capacité sont encore disponibles.
3. Le coordinateur sélectionne plat et dessert, ou soumet une proposition à valider.
4. L'équipe complète le nombre de convives et les informations de livraison pour préparer la production.
5. Des confirmations et rappels, notamment à 48 et 24 heures, aident chacun à vérifier son engagement.
6. Les responsables relisent le planning et les quantités avant de lancer les achats, la préparation et le service.

Le rappel n'est pas une preuve que la personne sera présente ; il donne une occasion de signaler tôt un problème. Le document exporté n'est pas non plus une commande fournisseur automatique. Son intérêt est de rendre l'état du planning lisible et partageable au bon moment.

Règles de réservation

La capacité quotidienne est limitée à trois affectations dans le périmètre décrit. Lorsque plusieurs personnes agissent au même instant, une vérification dans l'interface ne suffit pas : deux écrans peuvent afficher la dernière place libre. La base SQLite porte donc les contraintes essentielles et les changements liés sont enregistrés dans une transaction. Une tentative concurrente reçoit un refus clair si la place a déjà été prise.

L'annulation du coordinateur déclenche une règle précise. Un appui peut être promu au rôle de coordination ; la personne concernée doit alors pouvoir reprendre le choix du menu. Si la journée n'a plus aucun participant, le menu associé est libéré. Ce comportement évite de garder un plat affecté à un service qui n'existe plus. L'administration peut encore intervenir pour résoudre une situation particulière, mais l'état de base reste cohérent.

Cette règle montre pourquoi un planning est plus qu'un calendrier coloré. Le rôle détermine qui choisit le menu, reçoit certains rappels et répond de la préparation. Si une personne change de rôle, les droits et les messages doivent suivre la nouvelle situation. Une opération atomique évite de laisser une journée avec un menu verrouillé et sans personne autorisée à le gérer.

Menus et diversité

Le catalogue évite de saisir à chaque fois des intitulés libres impossibles à rapprocher. La règle de diversité hebdomadaire empêche la répétition du même choix dans la semaine selon les catégories retenues. Une vérification transactionnelle limite les collisions lorsque deux coordinateurs choisissent simultanément le même menu. La contrainte porte sur l'organisation du planning, pas sur une appréciation nutritionnelle ou culinaire automatisée.

Un dessert personnalisé passe par l'administration, ce qui permet de vérifier sa faisabilité avant de l'annoncer à l'équipe. Si la proposition est refusée ou reste en attente, elle ne doit pas être traitée comme un dessert validé dans les exports. Le menu de chaque jour garde son statut visible pour éviter qu'un document de production parte avec un choix encore provisoire.

Quantités et logistique

Les recettes servent de base à un calcul proportionnel : ingrédients de référence par personne multipliés par le nombre de convives prévu. Les liens vers les fiches de préparation permettent de retrouver les gestes et les consignes déjà documentés. L'export hebdomadaire rapproche les jours, les menus, les personnes affectées et les quantités théoriques.

Ce calcul est un point de départ. Il ne remplace pas l'ajustement d'un cuisinier ou d'un responsable de production : rendement réel, pertes, conditionnement, régime particulier et nombre final de portions peuvent le modifier. Le périmètre documenté ne prouve pas que l'outil gère les allergènes ou les obligations de traçabilité. Ces décisions et vérifications doivent rester dans les procédures adaptées de l'activité traiteur.

Les détails de livraison, lorsqu'ils sont renseignés, donnent un contexte opérationnel au planning. Il faut distinguer un service planifié d'une livraison confirmée : le calendrier ne garantit ni le transport ni le maintien des températures. Le PDF ou le tableur récapitulatif facilite la coordination, sans se substituer à ces contrôles.

Rappels, exports et changements

La confirmation initiale et les rappels à 48 et 24 heures visent les personnes engagées sur un jour de service. Les envois doivent refléter l'état courant : une annulation ou une promotion de rôle peut changer le destinataire et le message. Une équipe doit pouvoir consulter le planning directement plutôt que se fier uniquement à un ancien courriel.

Les exports PDF et XLSX répondent à deux usages : diffuser un document stable et retravailler une vue tabulaire. Ils comprennent les paramètres connus au moment de leur génération. Si l'effectif ou le menu change ensuite, le responsable doit produire une nouvelle version. C'est particulièrement important pour les achats et la production, où un nombre de convives périmé peut entraîner un écart concret.

Un export peut être relu selon trois questions simples : qui est présent, que doit-on préparer, et sur quel nombre de convives repose le calcul ? Si l'une de ces informations manque ou reste provisoire, le document doit le signaler. La liste d'ingrédients donne une préparation théorique par recette ; elle ne sait pas si le stock existe déjà ou si un fournisseur livrera à temps. Le responsable garde donc une étape de validation avant l'achat.

Ce que l’IA apporte réellement

L'IA a aidé à cadrer et à développer l'application. Elle ne compose pas les menus au hasard, ne réserve pas une place à la place d'une personne et ne valide pas une proposition culinaire. À l'exécution, les rôles, capacités, collisions, statuts et calculs de quantités suivent des règles déterministes.

Ce choix rend le système prévisible. Un refus de réservation s'explique par une place déjà occupée ; une quantité s'explique par une recette et un effectif ; un menu indisponible s'explique par la règle de diversité ou son état d'approbation. Les responsables conservent la main sur les exceptions.

Ce qui change pour l'équipe

Le bénéfice recherché est une coordination plus fiable. Les éléments fournis ne démontrent ni réduction mesurée des oublis ni diminution chiffrée des pertes alimentaires. Ces effets se vérifieraient en suivant les changements tardifs, les conflits de planning, les écarts entre convives prévus et servis, et les corrections d'achats.

Les limites à prévoir

La fenêtre de cinq semaines et les trois rôles quotidiens correspondent au besoin initial ; une autre organisation demanderait d'adapter ces paramètres. Les recettes et le nombre de convives doivent être tenus à jour. Les rappels dépendent de coordonnées valides et de la bonne délivrance des messages.

Le planning ne dispense pas des contrôles de production, d'allergènes, de conservation et de livraison. Ces sujets dépassent les fonctions décrites dans le projet. L'outil gagne à rester précis sur ce qu'il organise : personnes, menus, quantités indicatives et circulation de l'information.

Repères techniques

Node.js / ExpressSQLiteNotificationsPDF / Excel

Ces choix décrivent le périmètre présenté. Une reprise dans un autre contexte commence par la validation des usages, des données et des accès.