Guide · Ultineo SaaS
Du cahier des charges à la première version
Ce guide s'adresse au dirigeant ou au responsable dont le cahier des charges est arrêté et dont le logiciel va être construit. Vous saurez distinguer trois états (construit, testé, en ligne), tester avec vos propres cas et rédiger une demande de changement vérifiable. Il fait suite au guide « De l'idée au cahier des charges », où ces cas sont rédigés.
Vérifié sur le produit en novembre 2026
Construit, testé, en ligne : trois états différents
- Construit, en développement
Le travail existe, à l'endroit où arrive tout ce qui est nouveau. Il peut encore changer, et aucun utilisateur n'en dépend pour l'instant.
- Testé, en préproduction
Une version figée a été vérifiée avec vos propres cas, dans un endroit prévu pour cela. Vous savez exactement ce qu'elle contient.
- En ligne, en production
La version que vous avez vérifiée sert désormais vos utilisateurs. Un cas que vous n'avez pas vérifié, ce sont eux qui le rencontreront les premiers.
- Ce que permet « construit »
Vous pouvez essayer chaque parcours et demander des changements. Vous ne pouvez pas encore dire à un utilisateur que cela fonctionne.
- Ce que permet « testé »
Vous pouvez décider de publier, ou d'attendre. Dans les deux cas, votre décision porte sur une version qui ne bouge plus.
- Ce que permet « en ligne »
Vous pouvez prévenir vos utilisateurs, une fois la tâche modifiée refaite en production. Le changement suivant repassera par les trois mêmes états.
1. Faites d'abord construire le parcours qui est prêt
Un cahier des charges arrêté ne signifie pas qu'il faut tout construire d'un coup. Commencez par le parcours dont toutes les règles sont décidées : chaque question a sa réponse, chaque exception est écrite.
Une partie dont une question reste ouverte attend son tour. Ce qui est construit sur une règle non décidée devra peut-être être demandé une seconde fois.
Exemple. L'atelier qui répare des machines à café pour des cafés a un cahier des charges arrêté. Son premier parcours est décidé : une réparation demandée, attribuée et confirmée. Une question reste ouverte sur les rappels envoyés aux cafés : ils attendent, et le parcours de réparation est construit en premier.
Dans Ultineo. Un projet est ouvert dans Ultineo SaaS après l'étude de votre demande par notre équipe, et votre logiciel est ensuite conçu et construit avec vous. Dans l'espace du projet, une feuille de route organise la construction d'un domaine prêt en plusieurs phases. Ouvrez Modules et répondez aux questions du domaine, puis ouvrez « Créer une roadmap », choisissez le domaine dans Module et cliquez sur « Lancer la roadmap ». Le formulaire de lancement propose uniquement le travail éligible.
2. Répondez à ce qui vous attend
Pendant la construction de votre logiciel, deux listes comptent : le travail en cours et le travail qui vous attend. Seule la seconde a besoin de vous : lisez-la à jours fixes.
Répondez à chaque question dans l'élément qui la pose, avec la règle, un cas habituel et une exception. N'envoyez pas de nouvelle demande sur un travail déjà en cours.
Exemple. Lundi, la responsable trouve une question en attente : deux réparations peuvent-elles partager un créneau ? Sa réponse : un technicien a une seule réparation par créneau de deux heures. Cas habituel : le créneau est libre, il est attribué. Exception : il a été pris une minute plus tôt ; la personne qui attribue voit alors un message et choisit un autre créneau.
Dans Ultineo. Pour suivre la construction, cliquez sur Détail pour la feuille de route concernée et ouvrez ses phases : vous y lisez leur séquence, leur état actuel et leur progression. Cliquez sur l'icône des tâches dans la barre du haut : « À faire » présente les éléments qui demandent une réponse, « En cours » le travail déjà en traitement. Lorsqu'un élément pose une question, ouvrez « Répondre aux précisions », complétez « Vos réponses » et cliquez sur « Envoyer mes réponses ».
3. Testez ce qui est construit avec vos propres cas
Construit veut dire que cela existe, pas que c'est juste. Reprenez la liste de tests de votre cahier des charges et déroulez chaque ligne sur les vraies pages : le cas habituel, puis l'exception. Cette vérification au regard du cahier des charges, c'est ce que l'on appelle la recette.
Suivez chaque parcours jusqu'au bout, y compris la page vers laquelle il mène ensuite. En face de chaque ligne, notez réussi ou échoué, et ce que vous avez vu.
Exemple. La responsable déroule ses six lignes sur les pages construites. Cinq réussissent. La quatrième échoue : une réparation sans numéro de série devrait être conservée et impossible à attribuer, or la page permet de l'attribuer. Elle note la page, ce qu'elle a fait et ce qu'elle a vu.
Dans Ultineo. Dans l'espace du projet, le développement est l'environnement qui reçoit le travail. Repérez les fonctions et les pages réalisées par la feuille de route, ouvrez l'application de développement et testez les parcours prévus et leurs exceptions importantes. Dans les détails d'une page, Informations présente le comportement et le périmètre prévus : comparez-les avec ce que vous voyez. La fin d'une feuille de route indique l'avancement de la construction : vérifiez séparément la version de l'environnement avant d'annoncer un changement en ligne.
4. Rédigez chaque demande de changement pour qu'elle soit vérifiable
Une ligne qui échoue devient une demande de changement. Écrivez quatre choses : la page, ce qui se passe aujourd'hui, ce qui devrait se passer et un exemple à rejouer. Celui qui la lit doit pouvoir reproduire le problème puis, plus tard, vérifier la correction.
Demandez un seul résultat par demande. Deux changements sans lien dans la même phrase se masquent l'un l'autre, et aucun ne peut être vérifié seul.
Exemple. Vague : « Le numéro de série ne marche pas. » Vérifiable : « Sur la page d'attribution d'une réparation, une réparation sans numéro de série peut aujourd'hui être attribuée. Elle devrait rester dans la liste, avec un message qui nomme le champ manquant, et ne pas pouvoir être attribuée. Exemple : la demande du café de test, envoyée sans numéro de série. »
Dans Ultineo. Un changement sur une page déjà construite se prépare dans l'écran nommé « Demandes IA ». Ouvrez la page construite et copiez son adresse, collez-la dans « Nom ou URL de la page », puis décrivez le fonctionnement actuel, le résultat attendu et un exemple concret. La flèche « Ajouter à la liste » prépare une ligne ; « Tout envoyer » soumet les demandes préparées. Suivez la demande dans « Modifications en cours », puis testez la page en développement.
5. Créez une version, puis vérifiez-la en préproduction
Le développement change sans cesse : on ne publie pas « ce qui est en développement ». On publie une version, c'est-à-dire un ensemble nommé de changements qui ne bouge plus. Vérifiez-la en préproduction, l'endroit où une version choisie se contrôle avant que les utilisateurs ne la voient.
Refaites-y les parcours modifiés, l'étape qui suit chacun et une exception importante. Notez la version que vous avez vérifiée : c'est celle-là que vous publierez.
Exemple. Les six lignes réussissent désormais en développement. Une version est créée, et la responsable refait les six lignes sur cette version en préproduction, puis lit la confirmation comme le ferait un café, sur un téléphone. Elle note la version à côté de la date de sa vérification.
Dans Ultineo. Ouvrez Déploiement et repérez « Version de votre projet ». Lorsque des changements sont disponibles, utilisez « Créer une version » : une version regroupe les changements à publier. Cliquez sur « Déployer en Pré-production », attendez la mise à jour de la version, puis ouvrez le service de préproduction et testez les parcours modifiés dans les langues nécessaires. Pour une première version, Lancement présente chaque étape de ce parcours : la préproduction et la production ne sont installées qu'après un clic sur « Mon environnement de développement est validé ».
6. Publiez, puis vérifiez ce qui est en ligne
Publier est une décision, pas la dernière minute de la construction. Prenez-la quand la version en préproduction a réussi tous les tests de votre liste et que tout ce dont la production a besoin est en place, à commencer par l'adresse que vos utilisateurs ouvriront.
Après la publication, lisez quelle version est en production et refaites une fois la tâche modifiée, comme le ferait un utilisateur. Alors seulement, prévenez vos utilisateurs.
Exemple. La version est publiée un mardi matin. La responsable lit la version indiquée pour la production, demande une réparation comme le ferait un café, l'attribue, lit la confirmation, puis l'annule. Elle écrit ensuite à ses trois premiers cafés.
Dans Ultineo. Pour une première version, la production attend que vos domaines soient déclarés et pointent vers l'adresse indiquée sur votre page des domaines. À l'étape de relecture de cette première publication, cliquez sur « J'ai relu ma version » après avoir vérifié la version en préproduction. Sur la ligne Production de « Version de votre projet », cliquez sur « Mettre en production », attendez que Production affiche la version voulue, puis ouvrez le service en ligne et reproduisez la tâche modifiée.
Aide-mémoire
Avant de prévenir vos utilisateurs
- 1. Choisissez le premier parcours
Celui dont les règles et les exceptions sont toutes décidées ; le reste attend.
- 2. Lisez ce qui vous attend
Répondez à chaque question ouverte par une règle, un cas habituel et une exception.
- 3. Testez en développement
Déroulez chaque ligne de votre liste de tests sur les pages construites et notez ce que vous avez vu.
- 4. Rédigez des demandes vérifiables
La page, ce qui se passe aujourd'hui, ce qui devrait se passer et un exemple, avec un seul résultat par demande.
- 5. Vérifiez la version en préproduction
Les parcours modifiés, l'étape suivante de chacun et une exception, sur la version que vous publierez.
- 6. Vérifiez ce qui est en ligne
Lisez la version en production et refaites la tâche avant de prévenir vos utilisateurs.
Pour aller plus loin
- Fonctionnalités
- Articles d'aide
Construisez votre logiciel avec Ultineo SaaS
Envoyez votre demande : notre équipe étudie chacune d'elles avant l'ouverture du projet.
Questions
Non. Dans Ultineo SaaS, une feuille de route organise la construction d'un domaine prêt en plusieurs phases. Les fonctions et les pages convenues expliquent toujours ce qui doit être réalisé et servent de référence à la vérification.
Elle décrit le fonctionnement actuel, le résultat attendu et un exemple concret. Une demande utile décrit une action, une exception et le résultat visible à vérifier. Préparez des demandes distinctes pour les changements sans lien, plutôt qu'une seule demande avec plusieurs résultats.
Dans Ultineo SaaS, une demande de changement sert à demander une modification ciblée d'une page existante ; un retour, envoyé avec Signaler, enregistre un problème, une idée ou une question. Le guide « Faire vivre son logiciel après la mise en ligne » montre comment signaler un problème pour qu'on puisse le reproduire.
Parce que les trois environnements ont des rôles distincts : le développement reçoit le travail, la préproduction vérifie une version et la production sert les utilisateurs. En préproduction, vous vérifiez cette version et ses parcours complets, avec leurs liens et leurs exceptions importantes.
Déploiement indique le prérequis. Il peut manquer une version, un test en préproduction ou un domaine vérifié, ou une demande peut être en cours. Résolvez la condition indiquée : répéter l'envoi ne termine pas un prérequis manquant.
Parce que la fin de la construction ne publie pas une version. Vérifiez le résultat en développement, créez la version du projet, testez-la en préproduction, puis contrôlez la version après la mise en production. Ouvrir ou redémarrer un environnement ne publie pas non plus, à lui seul, les derniers changements.