Laissez-moi vous faire visiter un compte réel, du début à la fin, plutôt que de décrire la barre latérale élément par élément. Disons qu'il s'agit d'un freelance, sa première semaine sur la plateforme, en train de créer une application de suivi d'habitudes pour un petit client. Voici ce qui arrive à ce build en parcourant le tableau de bord, dans l'ordre où cela se produit réellement — et où chaque étape a soit fait gagner, soit fait perdre cinq minutes.
Le prompt
Ils ouvrent AI Builder et tapent quelque chose comme « crée-moi un suivi d'habitudes ». C'est une première phrase raisonnable, mais un mauvais prompt final. Ce qui revient n'est pas du code — c'est un plan, rédigé en langage clair, et si vous vous arrêtez à « ça a l'air bien » et cliquez sur approuver, vous obtenez quelque chose de techniquement en phase avec les mots « suivi d'habitudes » et générique sur tout le reste. Le client du freelance ne voulait aucune fonctionnalité sociale, un stockage local uniquement, et le mode sombre par défaut. Rien de tout cela n'était dans le premier prompt. Ça passe plutôt dans le plan, sous forme de trois modifications avant approbation : supprimer la fonctionnalité « partage ta série » que le plan a inventée de lui-même, remplacer la ligne de stockage, basculer le thème par défaut. Trente secondes de retouche. Le build qui en ressort correspond au brief au lieu de correspondre aux mots « suivi d'habitudes ».
L'étape du plan que tout le monde saute
J'ai vu ce moment précis mal tourner pour d'autres utilisateurs — approuver le premier plan sans le lire, se retrouver trois itérations plus loin, et devoir réexpliquer des contraintes qui auraient dû être posées dès l'étape du plan. L'étape du plan existe précisément pour éviter ça. Elle ne coûte presque rien, et c'est le seul moment de la boucle où vous négociez avec l'agent dans votre langage, au lieu de déboguer son résultat dans le code.
Où le build atterrit réellement
Une fois généré, le suivi d'habitudes apparaît sous forme de carte dans My Builds — la page bibliothèque, filtrable par type, et la page que ce freelance ouvrira le plus souvent dès la troisième semaine, une fois cinq ou six builds accumulés. Il n'apparaît pas dans Showcase ; cette page est sélectionnée manuellement, pas automatique, et un build client qui y figure sans y être invité serait le mauvais réflexe par défaut. Il n'apparaît pas non plus dans Templates, sauf si le freelance pense à l'enregistrer comme tel — ce qui vaut vraiment le coup ici, car un squelette de suivi d'habitudes est exactement le genre de chose qu'un freelance reconstruit pour le client suivant avec une autre identité visuelle. La plupart des gens ne découvrent « enregistrer comme modèle » qu'au sixième build, en regrettant de ne pas l'avoir fait dès le premier.
Publié, ou quelque chose de plus lourd
Vient ensuite la question de la diffusion. Trois vraies options, pas une seule option avec trois noms. Published offre un sous-domaine gratuit, en ligne en quelques secondes, sans configuration — le bon choix tant que le client est encore en phase de relecture et pourrait demander une refonte. Domain Management intervient quand le domaine propre du client est prêt à pointer dessus, et cette étape a un double rôle : connecter un domaine ici, ce n'est pas juste changer d'URL, c'est aussi ce qui donne aux pages d'analyse plus bas dans la barre latérale quelque chose auquel se rattacher. Deploy, dans les paramètres, est la voie SFTP pour quand le client insiste pour que le build tourne sur une infrastructure qu'il contrôle — plus de configuration, et le freelance ne porte plus du tout la responsabilité de la disponibilité, un compromis réel qu'il vaut mieux poser explicitement plutôt que de le découvrir par accident.
Pour ce build, Published d'abord. Passer du sous-domaine au domaine personnalisé plus tard ne pose aucun problème. Annuler un déploiement en domaine personnalisé sur un projet client qui est annulé demande plus de nettoyage que ça n'en vaut la peine — et le freelance s'est d'ailleurs déjà fait avoir exactement de cette façon sur un projet précédent, ce qui explique toute la raison d'être du réflexe « Published par défaut ».
Le détour par les stores d'applications
Ce client particulier voulait aussi une fiche sur les stores d'applications, donc le build passe par Shipped au lieu de s'arrêter à Published — une page qui existe parce que la validation des stores est asynchrone d'une manière que les déploiements web ne sont tout simplement pas. Soumettez à un store et ça patiente deux jours ; soumettez à un autre et ça passe en vingt minutes. Shipped permet de suivre tout ça sans ouvrir cinq onglets de navigateur vers cinq consoles de stores différentes, chacune avec son propre identifiant et son propre vocabulaire de statut.
La page vide dont personne ne les avait prévenus
Une semaine après la connexion du domaine, le freelance ouvre Search Performance pour vérifier. Vide. Même un peu triste, en fait — pas de graphique, pas de chiffre, juste une invite à connecter un compte. Ce n'est pas cassé, c'est honnête : il n'y a tout simplement pas encore de données, car Search Performance, Google Analytics et Store Analytics dépendent tous de la connexion au compte Google dans les paramètres, et aucun ne récupère de données rétroactivement. La synchronisation démarre au moment de la connexion, uniquement vers l'avant. Connectez le domaine dès le premier jour et vous avez une semaine d'historique à la deuxième semaine ; connectez-le le dixième jour parce que vous avez oublié, et vous repartez de zéro ce dixième jour. Le freelance avait connecté le domaine mais pas le compte Google — deux étapes distinctes qui donnent l'impression d'en être une seule.
Ce qui coûte réellement quelque chose ici, ce n'est pas le graphique manquant. C'est que les agents d'optimisation lisent ces mêmes données, et un agent chargé d'améliorer le classement d'une page sans aucun historique Search Performance derrière lui travaille à partir de bonnes pratiques générales au lieu des chiffres réels de ce site. Sauter la connexion ne se contente pas de laisser une page de tableau de bord vide — cela limite aussi ce que les agents peuvent accomplir.
Le brief qui apparaît sans qu'on le demande
Deux semaines plus tard, une carte apparaît dans Discovery : un brief d'opportunité signalant une lacune de contenu sur le site du client, avec un bouton Créer attaché. Vraiment utile quand ça tombe sur quelque chose que vous auriez de toute façon fait. Mais Discovery privilégie volontairement le volume plutôt que la précision — plus de briefs que ce que quiconque peut traiter — donc la bonne posture est celle d'une boîte de suggestions, pas d'une file à vider. Le freelance la parcourt tous les quelques jours et en ignore la plupart, ce qui est l'usage prévu, pas un signe de retard.
Les réglages qui auraient dû être faits dès le premier jour
À ce stade, le freelance est passé par quatre pages de réglages sans jamais ouvrir le menu des paramètres délibérément — chacune découverte parce qu'autre chose était vide.
| Page | Ce que ça conditionnait en réalité |
|---|---|
| Comptes Google | Search Performance, Google Analytics et les données de référence des agents — une seule connexion, trois surfaces |
| Déployer | Cibles SFTP, nécessaires uniquement pour le parcours serveur contrôlé par le client |
| Médias IA | Réglages par défaut de génération d'images utilisés dans les créations |
| Forfaits et crédits | Quota d'utilisation, packs de crédits, reçus |
Comptes Google est celui qu'il vaut mieux régler en priorité. C'est un point de connexion unique derrière trois surfaces de tableau de bord distinctes, et le découvrir à la dure — trois pages vides différentes, trois moments différents de « ah, il faut que je connecte quelque chose » — est exactement la friction qu'une configuration de cinq minutes le premier jour permet d'éviter.
Les deux choses qui étaient là depuis le début
Le bouton flottant Ask-AI était présent sur chacune de ces pages depuis le début, et ce n'est pas un chatbot FAQ limité — il peut connecter un compte, lancer une création, ou expliquer pourquoi une page est vide, en votre nom. Le client du freelance, non anglophone, avait besoin de toute l'interface dans une autre langue pour un appel de révision ; le globe dans la navigation bascule les vingt langues, en cours de session, sans perdre la création en cours. Aucune des deux choses n'avait besoin d'être découverte par tâtonnement comme tout le reste dans ce parcours. Elles étaient simplement là.
C'est le résumé honnête des deux premières semaines de ce compte — pas « lire la doc, puis créer », mais l'inverse. My Builds était une abstraction jusqu'à ce qu'une carte y apparaisse. Search Performance était un état vide jusqu'à ce qu'un domaine l'alimente. Lire le plan avant la première création est un bon contexte de fond, mais le plan ne prend tout son sens que lorsqu'il y a un vrai suivi d'habitudes quelque part dedans.
