Par Thomas Cohen, fondateur de Maestro
Beta Maestro : demander un accès et préparer son premier projet
Comment demander votre invitation, préparer vos accès IA et choisir un premier essai utile. Un guide pour découvrir Maestro sur Mac avec un objectif clair et des attentes réalistes.
La beta de Maestro permet de découvrir une autre façon de construire une application : vous décrivez votre besoin, une équipe d'agents IA prépare et réalise le travail, puis vous examinez les résultats. Pour en tirer quelque chose, le plus utile est de commencer avec une petite question à résoudre. « Est-ce que je comprends et peux corriger le brief de mon projet ? » constitue déjà un premier essai sérieux.
L'accès se demande sur invitation, pour macOS 13 ou une version ultérieure. Maestro est gratuit pendant la beta ; l'utilisation de l'IA dépend de votre fournisseur et peut être facturée séparément. Les invitations arrivent par vagues. Ce guide explique quoi préparer avant l'accès, quoi observer pendant votre découverte et comment transmettre un retour exploitable.
Nous suivrons un exemple fictif : Camille répare des vélos. Elle aimerait retrouver les réparations à faire et les pièces qui manquent, sans parcourir plusieurs notes. Son atelier, ses clients et les situations ci-dessous sont inventés. Ils servent à montrer comment essayer Maestro sans confier immédiatement son activité à une application en construction.
1. Demander une invitation et comprendre ce qu'elle signifie
Le formulaire d'accès beta se trouve sur la page d'accueil. Indiquez une adresse que vous consultez, votre système et la langue souhaitée pour les emails. L'inscription permet de demander un accès et d'être prévenu de l'ouverture de votre vague. Elle ne déclenche pas un téléchargement public ni une activation immédiate.
Aucun délai d'invitation garanti n'est annoncé. Vous pouvez profiter de l'attente pour préparer votre cas d'essai ; inutile de repousser toute réflexion jusqu'à la réception de l'accès. Gardez l'adresse utilisée lors de l'inscription pour retrouver les informations qui vous seront envoyées. Les consignes reçues avec l'invitation constituent la référence pour l'installation de votre version.
Une beta est une période pendant laquelle le produit continue d'évoluer avec les retours des personnes qui l'utilisent. Vous pouvez rencontrer des défauts, des formulations peu claires ou un comportement qui change entre deux versions. Prenez votre premier projet comme un essai délimité, avec une copie de travail et des données inventées.
2. Préparer son Mac et un espace d'essai
Vérifiez la version de macOS dans les informations de votre ordinateur. Si vous êtes sur Windows, l'inscription peut servir à être prévenu, mais elle ne transforme pas la beta actuelle en version compatible. Ne préparez pas un essai qui dépend d'un système encore indisponible. Pour un Mac professionnel, vérifiez aussi les règles d'installation de votre organisation.
Choisissez un projet dont vous comprenez le métier et les résultats attendus. Camille connaît la différence entre un vélo en attente de pièce et un vélo prêt à rendre ; elle pourra donc repérer une confusion. Un sujet totalement nouveau vous obligerait à apprendre à la fois le métier, la méthode et l'outil.
Préparez trois ou quatre exemples fictifs : une réparation à commencer, une réparation bloquée et une réparation terminée. Donnez-leur des noms clairement inventés. Ces exemples deviendront votre petit jeu d'essai, réutilisé à chaque modification. Vous pourrez comparer deux versions sans vous demander si les différences viennent des données ou du travail réalisé.
Créez également une note personnelle avec votre objectif, vos questions et le résultat de chaque essai. Conservez les documents importants hors de votre seul projet de découverte. Une copie séparée aide à reprendre vos observations si l'application rencontre un problème. Elle ne remplace pas une stratégie de sauvegarde pour un futur usage professionnel.
3. Distinguer Maestro, l'assistant IA et le modèle
Maestro organise le travail et les validations. L'assistant IA est le service auquel vous confiez les tâches. Le modèle est le moteur utilisé par cet assistant pour comprendre les demandes et produire ses réponses. Ces trois niveaux n'ont pas forcément le même compte, les mêmes réglages ou la même facturation.
Les assistants annoncés comme compatibles sont Claude Code, Codex, Cursor et Mistral Vibe. Pour commencer, choisissez un accès que vous comprenez déjà, ou prenez le temps de vérifier ses conditions. Le fait d'avoir un compte auprès d'un fournisseur ne signifie pas que tous ses produits et tous ses usages sont compris dans votre offre.
Repérez où vérifier votre consommation, comment vous reconnecter et quelles limites s'appliquent. Suivez les indications de connexion de votre version de Maestro et les instructions du fournisseur. Vous n'avez pas besoin de comparer tous les modèles avant votre première séance. Il suffit de pouvoir expliquer quel service travaille et qui facture son utilisation.
Ne mettez jamais un mot de passe ou une clé d'accès dans la description du projet, une capture publique ou un message de retour. Utilisez le parcours de connexion prévu. Si vous ne savez pas si une information est un identifiant public ou un secret, demandez une explication avant de la partager.
Préparer une enveloppe simple
Choisissez une dépense maximale pour votre découverte et un moment où vous regarderez la consommation. Cette enveloppe personnelle n'est pas un tarif recommandé ni une estimation du coût d'une application complète. Elle sert à éviter de poursuivre une série d'essais sans voir ce qu'elle consomme.
Séparez le coût de votre accès IA, les éventuels usages facturés en plus et les futurs frais de fonctionnement de l'application. L'hébergement, un domaine ou un service d'envoi d'emails peuvent devenir pertinents plus tard. Ils ne sont pas automatiquement fournis parce que vous avez réussi à ouvrir un premier écran dans Maestro.
4. Choisir une première réussite suffisamment petite
Camille pourrait demander la gestion entière de son atelier : rendez-vous, devis, stock, factures, paiements et messages clients. Elle aurait ensuite beaucoup de choses à relire, sans savoir laquelle vérifier en premier. Pour découvrir la beta, elle retient une question : peut-elle décrire puis retrouver la prochaine réparation à faire ?
Son premier parcours consiste à ajouter une réparation fictive, lui donner un état et la retrouver dans une liste. Le résultat attendu tient en une phrase : « Je vois le vélo à préparer aujourd'hui et je distingue celui qui attend une pièce. » Les paiements, les notifications et le partage avec un collègue restent en dehors de cet essai.
Cette réduction facilite le retour. Si l'état affiché n'est pas le bon, Camille peut montrer une règle précise à corriger. Si elle a demandé toute son entreprise d'un coup, elle risque de répondre seulement « ce n'est pas ce que je voulais ». Le petit périmètre rend la discussion plus utile et le prochain changement plus facile à examiner.
Vous pouvez aussi consacrer votre première séance au cadrage, sans chercher à faire construire immédiatement. Une description juste du problème et un brief que vous savez corriger sont des résultats utiles. Décidez au début de ce que vous voulez apprendre ; n'ajoutez pas un nouvel objectif à chaque proposition de l'IA.
5. Raconter son besoin et relire le brief proposé
Voici une demande que Camille pourrait préparer : « Je répare des vélos dans un petit atelier. Aujourd'hui, je note les travaux et les pièces manquantes dans plusieurs endroits. Je voudrais retrouver les réparations à faire et distinguer celles qui attendent une pièce. Pour le premier essai, je suis la seule utilisatrice et toutes les données sont fictives. »
Elle ajoute une limite : « Je ne veux pas encore gérer les factures ni prévenir les clients. Commence par reformuler le besoin et les points que je dois décider. » Ce texte donne une direction sans imposer une technologie. Le guide décrire son idée à une IA propose une version encore plus courte à adapter.
Dans Maestro, Margaux intervient au cadrage pour transformer l'idée en brief. Ce document décrit notamment le problème, les personnes concernées, la valeur attendue et les risques. Relisez ce qu'il affirme sur votre activité. Une phrase fluide peut contenir une supposition que vous n'avez jamais validée.
Pour Camille, « tout vélo en attente doit être réparé aujourd'hui » serait faux. Certains attendent une livraison. Une correction utile serait : « Sépare les réparations disponibles de celles qui attendent une pièce ; ne leur attribue pas automatiquement une échéance. » Vérifiez ensuite que cette correction apparaît dans le document, au lieu de vous contenter d'un accord dans la conversation.
6. Comprendre ce que montre la démonstration Tablée
Tablée est l'exemple intégré qui permet de découvrir l'organisation de Maestro. Son parcours est scénarisé et son aperçu est une maquette interactive sans sauvegarde. Il aide à comprendre les points de vue proposés sur un projet ; il ne démontre pas que votre propre application fonctionne déjà.
Utilisez cette visite pour repérer ce que vous devrez relire, où se trouvent les tâches et comment un aperçu se présente. Dans les captures du Journal, les écrans Tablée montrent ce même exemple. Ils ne représentent pas l'atelier fictif de Camille et ne constituent pas le témoignage d'un client.
Quand vous passez à votre projet, reprenez votre propre liste de vérifications. Un écran préparé pour une visite et une application construite à partir de votre besoin n'ont pas le même statut. La visite de Maestro permet de découvrir la logique générale avant l'invitation ; les résultats de votre essai devront être observés séparément.
7. Essayer un parcours et noter ce qui s'est passé
Préparez le scénario avant de cliquer. Pour Camille : créer « Vélo exemple A », lui attribuer l'état « En attente de pièce », fermer puis rouvrir le parcours et retrouver le même état. Notez le résultat observé, même lorsqu'il ne correspond pas à votre attente. C'est une information de travail, pas un échec personnel.
Essayez ensuite une petite variation : une réparation sans description, un changement d'état ou un nom suffisamment long. Vérifiez si l'application explique ce qui manque et si les informations restent compréhensibles. Ces essais ne remplacent pas une revue technique ; ils servent à contrôler le comportement que vous avez demandé.
- Départ : les données fictives et l'écran sur lequel commence l'essai.
- Action : ce que vous faites, dans l'ordre.
- Résultat attendu : ce qui devrait apparaître ou être conservé.
- Résultat observé : ce qui s'est réellement passé.
- Décision : continuer, demander une correction ou suspendre l'essai.
Après une correction, rejouez le premier scénario avec les mêmes données. Un nouveau résultat ne prouve pas que le précédent fonctionne encore. Si une partie reste impossible à vérifier, écrivez-le clairement. Le guide des risques du développement avec l'IA explique comment étendre ces contrôles avant un usage réel.
8. Envoyer un retour qui aide à corriger
Un retour utile commence par ce que vous cherchiez à faire. « Je veux changer l'état d'une réparation » donne plus de contexte que « le bouton ne marche pas ». Ajoutez la version de Maestro, votre version de macOS et l'assistant utilisé si ces informations sont pertinentes. N'inventez pas une cause technique ; décrivez le symptôme.
Camille pourrait écrire : « Avec trois réparations fictives, j'ouvre Vélo exemple A, je choisis Terminé et je reviens à la liste. Je m'attends à lire Terminé. La liste affiche encore En cours. Le même essai produit ce résultat deux fois. » Le destinataire dispose alors d'un point de départ pour chercher et reproduire le problème.
Joignez une capture seulement si elle apporte une information, après avoir masqué les données privées, comptes et secrets. Un message d'erreur exact est souvent plus utile qu'une longue interprétation. Utilisez le canal indiqué dans votre invitation ou dans la version du produit que vous utilisez ; ce guide ne promet pas un délai de réponse particulier.
Distinguez le défaut et la suggestion. « L'état n'est pas conservé » concerne le comportement attendu. « J'aimerais pouvoir trier par date » ajoute un besoin. Présenter les deux séparément évite de confondre une correction nécessaire avec une évolution à discuter. Notez aussi une formulation qui vous a permis de comprendre : les retours positifs précis sont exploitables.
9. Décider de la suite après la découverte
À la fin de votre essai, reprenez l'objectif initial. Avez-vous compris le brief ? Pouvez-vous expliquer ce qui a été construit ? Avez-vous pu vérifier le petit parcours choisi ? Si vous répondez non, commencez par éclaircir ce point avant d'élargir le projet. La quantité d'écrans produits ne mesure pas à elle seule l'utilité de la séance.
Conservez une courte trace : ce qui fonctionne, ce qui bloque, ce que vous ne savez pas encore et votre prochaine décision. Camille pourrait choisir d'approfondir les états d'une réparation avant d'ajouter le stock. Elle pourrait aussi constater qu'une liste commune lui suffit. L'essai doit aider à décider, y compris lorsque la décision consiste à ne pas construire davantage.
Avant de confier des données réelles ou une activité quotidienne à l'application, préparez les accès, les sauvegardes, la maintenance et les conditions d'utilisation. Le stockage du projet sur votre Mac ne signifie pas que l'IA fonctionne hors ligne ; les assistants configurés peuvent recevoir du contexte. Les explications sur vos données détaillent cette distinction.
Pour prolonger le travail, le grand guide de création sans savoir coder suit le parcours jusqu'au premier usage réel. Pour commencer la découverte, préparez un besoin, trois exemples fictifs et une chose à vérifier, puis demandez votre invitation. Vous aurez un point de départ concret dès l'ouverture de votre accès.