Retour au parcours
Créer une application
Du template DSI à la première mise en ligne.
Une application comme MyuPrompt ne part jamais d'une page blanche. Elle naît d'un modèle commun, le dsi-template, puis suit une recette en quelques étapes. La démarche est la même que tu codes avec Replit ou avec Claude.
Le dsi-template, c'est quoi ?
Le dsi-template est le modèle de départ partagé par toutes les applications de la DSI MyUnisoft. Pense à un plan de maison déjà dessiné : les fondations, l'électricité et la plomberie sont posées, il ne reste qu'à aménager les pièces. Concrètement, il fournit déjà la connexion Microsoft, la base de données, les tests, la sécurité, le pipeline de livraison et les conventions DSI.
MyuPrompt — le guide que tu lis en ce moment — est justement issu de ce template. Partir du dsi-template, c'est gagner des semaines de mise en place et hériter automatiquement des bonnes pratiques maison.
Les variables du template
Au moment de créer le projet, le template te pose quelques questions. Voici ce que chacune signifie.
Nom
Le nom du projet
Le nom lisible de l'application (ex. « MyuPrompt »). Il sert d'identité au projet et apparaît un peu partout : dépôt, déploiement, interface.
Slug
L'identifiant technique
La version « machine » du nom (en minuscules, sans accent ni espace, ex. « myu-prompt »). Elle sert à nommer le dépôt GitLab, l'image Docker et les URL.
Desc
La description
Une phrase qui résume ce que fait l'application. Pratique pour s'y retrouver dans la liste des projets de la DSI.
GitLab
L'emplacement GitLab
Le groupe et le chemin où le dépôt sera créé sur GitLab. C'est là que le code vivra et que les pipelines tourneront.
Infra
Les options techniques
Les besoins particuliers du projet : a-t-il besoin d'une base de données ? d'un espace de stockage de fichiers (bucket) ? d'un envoi d'e-mails ? On coche ce qui s'applique.
Les étapes de création
De la création du projet jusqu'à la première mise en ligne, voici le chemin — applicable que tu utilises Replit ou Claude.
1
1. Créer le projet dans DevSI à partir du template
Dans DevSI (le portail interne de la DSI), tu crées un nouveau projet en partant d'un template, et tu sélectionnes dsi-template. C'est le point de départ commun à toutes les apps de la DSI.
2
2. Renseigner les variables du template
Tu remplis le formulaire du template : nom, identifiant technique, description, emplacement GitLab et options techniques (base de données, stockage, e-mails). Le détail de chaque variable est listé juste au-dessus.
3
3. Lancer la commande d'initialisation
Une commande d'initialisation assemble le projet : elle intègre les variables saisies, génère à la volée les secrets JWT (les clés qui sécurisent les sessions), crée la paire de clés SOPS (pour chiffrer les secrets), pose la variable correspondante côté GitLab et publie la clé publique. Tu n'as rien à faire à la main : la commande s'occupe de tout.
4
4. Le volet DevOps / Infra
En parallèle, l'équipe Infra met en place la plomberie : déclaration de l'application (un identifiant en preprod et un en prod), création des enregistrements DNS en .internal pour preprod et prod pointant vers l'IP du HAProxy, ajout de la configuration Zscaler pour relier l'URL au service HAProxy, puis ajout des secrets OIDC (connexion Microsoft) dans SOPS. Si l'app a besoin de stockage, l'Infra crée aussi le bucket et son utilisateur, et range les accès dans SOPS.
5
5. Le volet « nouveau projet d'IDE » (ex. Replit)
Côté outil de développement (Replit, Claude…), tu crées un nouveau projet, tu y branches le dépôt GitLab via le token npm GitLab, puis tu ajoutes les secrets nécessaires : token npm GitLab, token GitLab, secret JWT, mot de passe administrateur et connexion à la base de données (DATABASE_URL).
6
6. Donner la spécification à coder
Tu ajoutes au projet le fichier de spécification (au nom et à l'emplacement attendus), puis tu demandes à l'assistant IA de le lire et de coder le projet. Il crée des merge requests et les fusionne. Si un pipeline échoue, tu lui demandes simplement de le réparer.
7
7. Le merge déclenche le déploiement
À chaque fusion sur la branche principale, le déploiement en preprod se fait tout seul. Ton application est en ligne, prête à être testée.
Captures annotées
Les écrans clés du parcours de création, repérés étape par étape. Ces captures seront ajoutées progressivement.
1. Créer le projet dans DevSI
Capture à venir
Dans DevSI, on crée un nouveau projet à partir du template dsi-template.
1
Nouveau projet — le bouton qui démarre la création depuis un template.
2
Choix du template — on sélectionne dsi-template dans la liste.
3
Point de départ commun — la base partagée par toutes les apps de la DSI.
2. Le formulaire des variables du template
Capture à venir
Les questions du template : nom, identifiant technique, description, emplacement GitLab et options.
1
Nom & slug — le nom lisible et son identifiant technique (minuscules, sans accent).
2
Emplacement GitLab — le groupe et le chemin où le dépôt sera créé.
3
Options techniques — base de données, stockage (bucket), e-mails — on coche ce qui s’applique.
3. La configuration du projet d'IDE (Replit)
Capture à venir
Côté outil de développement, on branche le dépôt GitLab et on ajoute les secrets nécessaires.
1
Dépôt branché — le projet d’IDE est relié au dépôt GitLab via le token npm GitLab.
2
Secrets — token npm GitLab, token GitLab, secret JWT, mot de passe administrateur et connexion à la base de données.
3
Prêt à coder — on ajoute la spécification et l’assistant IA code le projet.
Comment le CdP récupère-t-il les secrets ?
Les secrets de l'étape 5 ne viennent pas tous du même endroit. Les tokens GitLab sont fournis par l'équipe DevOps : la DSI applique le principe du moindre privilège et préfère plusieurs clés étroites à une seule clé maître, ce qui limite les dégâts si l'une fuite. Le secret JWT et le mot de passe administrateur, eux, sont produits par le projet lui-même. Enfin, la connexion à la base de données (DATABASE_URL) est fournie par l'équipe en même temps que la base de l'environnement de développement.
npm
Le token npm GitLab
Une clé en lecture seule qui autorise le projet à télécharger les briques communes de la DSI (les composants @myunisoft). C'est l'équipe DevOps qui la crée dans GitLab et te la transmet ; tu la colles ensuite dans le gestionnaire de secrets de l'outil (Replit : Tools → Secrets).
GitLab
Le token GitLab
Une clé limitée au seul projet courant qui permet à l'assistant IA d'ouvrir et de fusionner les merge requests. Elle est elle aussi créée et fournie par l'équipe DevOps (dans les réglages GitLab du projet) ; tu la colles dans le gestionnaire de secrets.
JWT
Le secret JWT
Les clés qui sécurisent les sessions des utilisateurs. Tu n'as personne à solliciter : il est généré automatiquement — à la volée lors de l'initialisation du projet (étape 3) ou via le petit générateur dédié. Tu n'as qu'à recopier la valeur produite dans le gestionnaire de secrets.
Admin
Le mot de passe administrateur
Le mot de passe du tout premier compte administrateur de l'application. C'est l'équipe (toi ou la DSI) qui le choisit — un mot de passe robuste — puis il est rangé chiffré (SOPS) pour le déploiement et dans le gestionnaire de secrets pour le développement.
BDD
La connexion à la base de données
L'adresse qui dit à l'application où se trouve sa base de données et comment s'y connecter (on l'appelle DATABASE_URL). Pour l'environnement de développement, elle est fournie par l'équipe (DSI / Infra) en même temps que la base ; tu la colles dans le gestionnaire de secrets. Sans elle, le serveur local ne peut pas démarrer.
La règle d'or des secrets
Quel que soit le secret, il va toujours dans le gestionnaire de secrets de l'outil (Replit : Tools → Secrets), jamais en clair dans un fichier du code ni dans un commit. C'est valable que tu développes avec Replit ou avec Claude.
Et la base de données en production ?
La connexion à la base (DATABASE_URL) que tu colles dans le gestionnaire de secrets ne concerne que l'environnement de développement. En production, tu n'as rien à coller : la connexion à la vraie base est fournie automatiquement par la plateforme au moment du déploiement (via la configuration Kubernetes). C'est le principe « on construit une fois, on fait tourner partout » : le même code reçoit la bonne adresse de base selon l'environnement où il tourne. Inutile donc de demander ou de saisir une DATABASE_URL de production à la main.
Replit ou Claude : même recette
Les étapes 1 à 4 (template, variables, initialisation, infra) sont indépendantes de l'outil de développement. Seule l'étape 5 dépend de l'IDE choisi : le principe reste le même, qu'il s'agisse de Replit, de Claude ou d'un autre environnement.
Et après le merge ?
Une fois en preprod, c'est le parcours décrit dans la section « Le parcours d'une app » qui prend le relais : build, image Docker, déploiement Kubernetes, mise en ligne.