MOA / MOE : un projet mené à fond

Dans ce devoir de gestion de projet, on a eu une opportunité assez rare en contexte scolaire : jouer à fond les rôles MOA / MOE sur un cas quasi réaliste, avec un vrai client fictif, une vraie infra, et un rendu final qui ressemblait plus à un livrable d’ESN qu’à un simple devoir.

Le projet portait sur Les Saveurs d’Ici, une enseigne de restauration à thème avec un réseau de 200 franchises partout en France, en contrat d’infogérance avec une ESN fictive : SysNet Partners. L’objectif : concevoir puis déployer une solution de partage documentaire centralisée entre la maison mère et les 200 franchisés, en assumant clairement les rôles de MOA (moi) et de MOE (Titouan).

---

Le sujet : Les Saveurs d’Ici, SysNet Partners, et la séparation MOA / MOE

Côté contexte, le commanditaire était la direction générale des Saveurs d’Ici, qui a besoin d’un portail documentaire pour diffuser ses standards de marque, recettes, procédures, documents RH, charte visuelle, etc. à ses 200 restaurants franchisés.
Aujourd’hui, tout passe par des mails, des PDF qui circulent, des WhatsApp, et des versions obsolètes qui traînent partout : risque juridique, risque sanitaire, incohérence de marque, etc.

Dans ce setup, SysNet Partners (notre ESN) cumule deux casquettes :

• MOA déléguée (moi) :
  • recueil et formalisation des besoins métier,
  • rédaction de l’étude d’avant‑projet et du cahier des charges fonctionnel,
  • interface avec la direction des Saveurs d’Ici,
  • arbitrages sur la solution retenue (parmi plusieurs scénarios).
• MOE (Titouan) :
  • conception de l’architecture technique,
  • déploiement sur Proxmox VE HA,
  • intégration FortiGate, Active Directory, Zabbix, GLPI,
  • rédaction du dossier de déploiement et de recette (P2).

On a donc réellement joué la séparation MOA / MOE, tout en restant une seule petite “équipe projet”.

---

Phase 1 : l’avant‑projet, le CdCF et les choix stratégiques

La Phase 1 était une vraie étude d’avant‑projet : analyse de contexte, cartographie de l’existant, besoins fonctionnels / non fonctionnels, contraintes, analyse de risques, scénarios de solution, puis recommandation.

Quelques points marquants côté MOA :

• Contexte métier détaillé :
  • 200 franchises, tension entre autonomie des franchisés et respect strict des standards de la marque.
  • absence de portail documentaire central : risque de recettes/procédures obsolètes, non‑conformité réglementaire, confusion sur les fournisseurs référencés.

• Analyse des parties prenantes : direction générale, coordination réseau, RH, franchisés, SysNet, etc.

• Cahier des charges fonctionnel et technique :
  • publier / versionner des documents structurés par catégories (Recettes, Fournisseurs, RH, Charte),
  • accès simple en lecture pour 200 franchises via navigateur, sans infra locale,
  • authentification des éditeurs via AD, logs, supervision, intégration à l’existant (Proxmox, FortiGate, Zabbix, GLPI).
• Étude comparative de plusieurs solutions :
  • Solution A : Wiki.js on‑premise sur Proxmox (recommandée),
  • d’autres options on‑premise (BookStack, Nextcloud) et SaaS (SharePoint, Confluence, etc.), avec analyse coût / valeur / souveraineté.

La recommandation finale (MOA) : Wiki.js on‑premise sur Proxmox VE HA, PostgreSQL, NGINX TLS, intégration AD et supervision Zabbix, pour un coût logiciel nul et une très bonne intégration à l’infra existante.

---

Phase 2 : le déploiement, la recette… et le rush

La Phase 2 a été le “mode MOE à fond” :
dossier de déploiement et de recette complet, avec :

• Architecture cible : VM Debian 12 sur Proxmox VE HA, 4 vCPU, 8 Go RAM, 80 Go SSD, stack Docker (Wiki.js + PostgreSQL + NGINX), FortiGate en frontal, LDAPS vers AD, supervision Zabbix, intégration GLPI, stratégie de sauvegardes et PRA.

• Procédures détaillées :
  • création de la VM, configuration réseau / DMZ,
  • installation Docker & Docker Compose,
  • déploiement Wiki.js via docker-compose,
  • configuration NGINX + Let’s Encrypt,
  • intégration LDAP/LDAPS avec AD (groupes éditeurs/admins),
  • règles FortiGate, agent Zabbix, webhook GLPI, scripts de backup et procédure de restauration avec RTO 4h.
• Cahier de recette complet :
  • tests de sécurité (TLS, rôles, non indexation, séparation des profils, etc.),
  • tests fonctionnels (création de pages, upload PDF, recherche full‑text, interface en FR, responsive),
  • tests de performance et de résilience (charge, bascule Proxmox HA, déclenchement d’alertes Zabbix + tickets GLPI).

Sur le papier, tout ça est très carré. En vrai… on a aussi rushé.
Entre la profondeur attendue, le niveau de détail technique et le reste de la charge de travail, on a clairement eu des moments de “OK, là faut qu’on envoie”.
Mais c’est aussi ce rush qui a rendu le truc vraiment fun : on savait qu’on pouvait s’appuyer sur nos bases techniques, alors on s’est permis de viser un rendu “niveau pro” et pas juste “niveau rendu étudiant”.

---

L’IA comme copilote discret : comment on a vraiment travaillé

Ce projet, on ne l’a pas fait “à l’ancienne”.
On a utilisé l’IA (Claude, Perplexity, etc.) comme copilote :

• pour revoir certaines formulations et clarifier des parties du CdCF (Phase 1) ;
• pour challenger la structure du déploiement (Phase 2) : est‑ce qu’on oublie un volet ? un risque ? un test de recette ?
• pour s’inspirer de structures de documents pro (RACI, registre de risques, glossaire, etc.) et les adapter à notre contexte.

Mais le contenu clé restait le nôtre :

• le contexte client,
• les choix d’architecture (Wiki.js sur Proxmox VE HA, intégration AD, flux FortiGate, supervision Zabbix/GLPI, PRA),
• les scripts, les matrices de flux, le cahier de recette, le plan de communication franchisés, etc.,
  tout ça sortait de notre compréhension d’infra et de gestion de projet.

L’IA a joué le rôle de “pair qui relit, reformule et challenge” plutôt que d’auteur à notre place.

---

Le meilleur moment : quand le rendu dépasse le cadre “scolaire”

Ce qui a rendu ce devoir particulièrement satisfaisant, c’est le moment où on a pris conscience qu’on n’était plus simplement “dans les attentes du sujet”, mais qu’on commençait à bluffer positivement l’enseignante :

• le niveau de détail de l’AVP (Phase 1) :
  • contexte métier très posé,
  • analyse sérieuse des risques et contraintes,
  • étude de plusieurs scénarios avec vraie argumentation.
• la qualité du dossier de déploiement & recette (Phase 2) :
  • procédures techniques réalistes,
  • intégration propre dans une infra cohérente (Proxmox, FortiGate, AD, Zabbix, GLPI),
  • prise en compte de la communication, de l’adoption par les franchisés, et pas juste de la technique brute.

On s’est retrouvés avec un livrable qui avait vraiment la gueule d’un projet d’ESN pour une TPE/PME franchisée, pas juste d’un “devoir de gestion de projet”. Le fait d’avoir assumé le côté rush, de s’être amusés avec le sujet, et d’avoir utilisé l’IA comme amplificateur plutôt que béquille, a clairement joué dans le résultat final.

---

Ce que je retiens (et pourquoi je le publie ici)

De ce projet Les Saveurs d’Ici, je garde plusieurs points importants :

• La séparation MOA / MOE est beaucoup plus parlante quand on l’incarne vraiment (rôle d’ESN, client, contraintes, arbitrages) que quand on se contente d’une définition théorique.
• Un rush organisé, appuyé sur des bases techniques solides et un bon duo, peut produire un livrable très propre, même dans un cadre académique.
• L’IA (Claude, Perplexity…) est un excellent copilote dès qu’on sait ce qu’on veut faire et qu’on reste aux commandes.

Et surtout :
ce genre de projet est exactement ce que j’ai envie de documenter ici sur ce blog — des cas concrets, où la technique, la gestion de projet, l’humain et les outils modernes (dont l’IA) se mixent pour produire quelque chose dont on peut être fier.