Démarrez bien votre prochain projet… ou reprenez en main celui qui vous échappe.
OwlMeans construit le socle de votre app et son parcours principal, y compris ce que vous n’auriez pas pensé à demander. Essayez-la, peaufinez-la et continuez à la développer avec OwlMeans ou votre agent de code.
Votre prochain projet
Décrivez à qui il s’adresse et ce que ses utilisateurs doivent pouvoir faire. OwlMeans en tire une spécification, des user stories et une application que vous développez un parcours utile après l’autre.
- Relisez la spécification avant tout développement.
- Disposez dès le départ de la structure de l’application, de la connexion et des consignes pour les agents.
- Développez un parcours utile, essayez-le, puis choisissez la modification suivante.
Celui qui vous échappe
Partez de votre projet GitHub. OwlMeans lit le code, en reconstitue la spécification et les user stories, puis reconstruit le projet sur un socle que vous pourrez continuer à développer.
- Examinez ce que fait le projet et ce que sa conversion implique.
- Approuvez les étapes et consultez leur estimation avant de poursuivre.
- Gardez la documentation reconstituée, ou allez jusqu’à l’application reconstruite.
La conversion reconstruit l’application sur la stack OwlMeans. Pour migrer une base de données en production et reconnecter les services externes, prévoyez un chantier à part.
Comment fonctionne la conversion d’un projet
Des projets comme le vôtre
Les personnes et les projets ci-dessous sont fictifs : ils illustrent ce que vous pourriez construire. Ce ne sont pas des témoignages de clients.
L’atelier de réparation de Pierre
Pierre veut que ses clients réservent leurs réparations sans avoir à échanger de messages pour chaque créneau disponible. Son premier parcours relie une liste de prestations, un formulaire de réservation et le planning de l’équipe.
Le service d’assistance de Maya
Maya veut regrouper au même endroit les demandes de ses clients. Un client ouvre un ticket, un collègue le prend en charge, et tous deux peuvent en suivre l’avancement.
L’assistant de recherche de Léo
Léo a besoin de recherches qu’il puisse vérifier avant de s’en servir. Son agent collecte des informations avec des outils approuvés, cite ses sources et lui demande de relire le résultat.
Le CRM inachevé de Nina
Nina a un prototype devenu difficile à modifier. Elle peut en récupérer les contacts, les opportunités et les parcours de relance sous forme de stories, puis choisir ce qu’elle reconstruira en premier.
L’app de réservation de Pierre, de l’idée au premier parcours
Suivez une petite application de la planification au développement, jusqu’à une évolution ultérieure. L’exemple repose sur un portail client, dont les stories définissent les règles de réservation.
Les captures d’écran proviennent d’une exécution réelle de cette demande sur OwlMeans, en octobre 2026. Pierre, ses clients et leurs réservations sont fictifs.
-
Étape 1
La demande
Créez une app de réservation pour mon atelier de réparation. Les clients choisissent une prestation et un créneau disponible, puis voient leur réservation. L’équipe gère le planning. Les clients ne doivent voir que leurs propres réservations.
La demande de Pierre, sur l’écran de création de projet.
- La demande, telle que Pierre la formule
- Demander une spécification à OwlMeans
-
Étape 2
La spécification
OwlMeans transforme la demande en un plan que vous pouvez relire : prestations, créneaux disponibles, réservations, accès des clients et accès de l’équipe. Vérifiez les règles avant d’approuver le plan.
L’ébauche initiale met en place la page d’accueil et les espaces de l’application. Ses emplacements provisoires, chacun étiqueté au nom d’une story, montrent ce qu’il reste à développer.
La spécification, soumise à votre relecture avant tout développement.
- À qui s’adresse l’app et quelles actions nécessitent un compte
- Modifier le plan avant que rien ne soit développé
- Accepter le plan pour créer le projet
L’ébauche initiale de l’espace Invité. Des emplacements étiquetés tiennent la place des stories pas encore développées.
- La story que représente cet emplacement
- Un contenu d’exemple, en attendant que la story soit développée
-
Étape 3
Les premières stories reliées
En tant que membre de l’équipe, je peux publier les créneaux réservables pour chaque prestation.
En tant que client, je peux choisir une prestation et un créneau disponible, puis confirmer ma réservation.
Développez-les dans l’ordre prévu sur le tableau du projet, en commençant par le planning de l’équipe. Ensemble, elles forment le premier parcours utile, avec des données réellement enregistrées, des contrôles d’accès et une règle qui empêche de réserver deux fois le même créneau.
Les stories prévues sur le tableau du projet, dans l’ordre du parcours principal.
- Le planning de l’équipe passe en premier
- Puis les premières actions du client
- Lancer le développement d’une story
-
Étape 4
Un résultat qui fonctionne
Essayez le parcours développé : choisissez une prestation, réservez un créneau et retrouvez la réservation dans votre compte. Ouvrez ensuite la vue de l’équipe et vérifiez que la même réservation y figure.
Puis essayez avec un deuxième client : son compte ne doit pas afficher la réservation du premier.
La réservation d’un client de test, dans l’aperçu en direct.
- La réservation dans le compte du client
- Sa référence, que l’équipe voit aussi
La même réservation, dans le planning de l’équipe.
- La même réservation, identifiée par sa référence
- Le créneau reste occupé
Un deuxième client de test ne peut pas ouvrir la réservation du premier.
- Un refus fondé sur les règles d’accès de l’app
-
Étape 5
La prochaine petite évolution
Après avoir essayé l’app, Pierre veut que ses clients puissent demander un autre créneau. Ce sera la story suivante, qui s’appuie sur les données de réservation et les règles d’accès déjà en place.
Testez cette évolution sur téléphone comme sur grand écran. Veillez à ce que le premier parcours de réservation continue de fonctionner à mesure que l’application grandit.
La story suivante sur téléphone : un client demande un autre créneau.
- La réservation actuelle, qui garde son créneau pour l’instant
- Un nouveau créneau, choisi parmi ceux qui restent libres pour la même prestation
- La demande, enregistrée dans la même réservation
Le socle qui porte ce parcours
Le formulaire de réservation n’est que la partie visible. OwlMeans prépare la structure qui le relie au reste de l’application.
| Ce que contient l’app de Pierre | En quoi cela facilite la modification suivante |
|---|---|
| Une page d’accueil publique, un espace client et un espace pour l’équipe | Chaque public a sa place dans l’application et un chemin de navigation défini |
| Des définitions communes pour les prestations, les créneaux et les réservations | L’interface et l’API utilisent les mêmes structures de données |
| La connexion et des règles d’accès déclarées | Chaque story peut préciser qui a le droit de consulter ou de modifier une réservation |
| Des responsabilités séparées pour l’interface, l’API et les données | On sait où modifier un écran ; les règles de réservation restent rattachées à la logique de réservation |
| Les consignes du projet et les compétences de chaque package, dans le dépôt | Le prochain agent de code peut lire l’architecture et en suivre les conventions |
| Des pages pour les conditions d’utilisation, la confidentialité et les cookies | L’application prévoit déjà une place pour les informations juridiques que l’entreprise aura relues |
Si une story ultérieure demande des rappels ou un traitement long, passez par une tâche en arrière-plan, avec une file d’attente et un worker. Ajoutez ce runtime quand l’application en a besoin.
Le dépôt généré, dans l’éditeur de code de la plateforme.
- Le modèle des réservations, défini dans le package commun
- Des packages distincts pour l’API, le backend, les définitions communes, l’interface web et le worker
- Les consignes pour le prochain agent de code
Une équipe derrière chaque story
Des agents spécialisés prennent en charge l’analyse, le design, l’architecture, le développement, la correction et la QA. Chaque rôle a une mission précise dans un pipeline strict, de la spécification à l’implémentation.
| Étape | Ce qu’elle apporte |
|---|---|
| Analyse métier | Les utilisateurs, leurs objectifs et les stories à développer |
| UX et architecture | Les écrans, les données, les règles d’accès et les contrats entre les différentes parties |
| Développement | L’implémentation, conforme à cette conception et aux conventions communes |
| Correction et vérifications | Les retours du build et de l’exécution, les tentatives de réparation et les problèmes à examiner |
Les étapes rendent le processus reproductible et le résultat attendu explicite. Une exécution interrompue peut reprendre. Avant la mise en production, c’est toujours vous qui relisez et testez l’application.
Place à la prochaine évolution
Planifiez l’application, puis développez-la par étapes utiles. Utilisez un parcours, repérez ce qui doit changer et ajoutez la story suivante sur le même socle.
Commencer par votre premier parcours →Tout ce qui entoure votre parcours principal
Planification et développement
- Une spécification et des user stories à relire, avec une ébauche annotée de l’application avant tout développement.
- Des agents aux rôles spécialisés, et des étapes pour concevoir, implémenter et réparer chaque story.
- Un tableau du projet, un aperçu en direct, un éditeur de code et une console d’agent pour le travail au quotidien.
- Une estimation par étape, une progression visible et des exécutions que l’on peut reprendre.
Le socle de l’application
- Une interface web pensée d’abord pour le mobile, une page d’accueil publique et des espaces structurés pour les utilisateurs, l’équipe et l’administration.
- Du TypeScript full-stack, des contrats d’API partagés et le stockage des données dans PostgreSQL.
- La connexion par e-mail et OIDC/SSO, avec les utilisateurs, les organisations, les groupes et les permissions de l’application.
- Des réglages d’accès distincts pour Preview et Production, et des environnements de projet isolés.
- Des tâches en arrière-plan, des files d’attente et l’intégration de fournisseurs d’IA quand l’application choisie en a besoin.
- Des pages pour les conditions d’utilisation, la confidentialité et les cookies, à compléter et à vérifier selon votre activité.
Poursuivre le développement et livrer
- La connexion à GitHub et un dépôt qui contient le code, les consignes du projet et celles de chaque package.
- Le développement dans le navigateur, ou une connexion MCP depuis un agent de code compatible.
- Avec Pro : la publication en production, la gestion des domaines personnalisés et les réglages de connexion en production.
- L’interface de la plateforme, disponible en huit langues.
Apps web, chatbots, agents et pipelines de données
OwlMeans propose des architectures de départ pour différents types de travail. Choisissez le type d’application, puis définissez le comportement et les intégrations dont vos utilisateurs ont besoin.
Apps web full-stack
Des portails clients, des outils internes et des produits SaaS, avec leurs données, leurs rôles et des parcours qui fonctionnent
Chatbots
Des interfaces conversationnelles reliées aux données et aux actions de votre application
Agents IA
Des applications qui choisissent parmi des outils définis, accomplissent des tâches et soumettent leurs résultats à votre relecture
Pipelines IA de traitement de données
Des étapes définies pour extraire, transformer et vérifier l’information
Des points de départ prêts à l’emploi
Outils métier
Produits pour vos clients
Données, IA et jeux
Ces points de départ apportent une structure et des consignes. Ce sont vos stories qui définissent les règles métier, les intégrations et le premier résultat utile.
Un projet que votre prochain agent saura comprendre
Continuez à développer dans OwlMeans, connectez via MCP un agent de code compatible, ou poursuivez dans le dépôt avec vos propres outils. Les consignes du projet et celles de chaque package accompagnent le code.
Claude Code, Codex et d’autres agents de code généralistes peuvent prendre le relais. OwlMeans fournit la structure de départ spécialisée et le workflow sur lesquels ils peuvent bâtir.
Faire tourner l’application ailleurs implique aussi de configurer la base de données, la gestion des identités et les autres services. Le guide de passation présente les options.
Une équipe pour aller jusqu’au bout
Si vous préférez nous confier le projet, les Services OwlMeans le prennent en charge, de la gestion de produit à la livraison. Vous recevez l’application, son code source et des consignes sur mesure pour les agents qui poursuivront le développement.
