Plateforme
Une console full-stack pour une livraison logicielle IA sérieuse
Logs, base de données, réseau et erreurs — visibles à côté du chat, si bien que vous déboguez l'app avec des preuves et mettez les constatations directement dans votre prochain prompt.
La console full-stack est la surface de diagnostic à l'intérieur de Ciao Builder : logs, état de la base de données, requêtes réseau et erreurs, visibles à côté de la conversation. Contrairement aux builders IA qui vous laissent deviner quand quelque chose casse, la console montre ce qui s'est réellement passé à travers la stack — si bien que le prochain prompt porte des preuves, pas des spéculations, et les correctifs atterrissent sur la vraie cause.
Publié 2026-07-03 · Dernière mise à jour 2026-07-03
Déboguer une app que vous n'avez pas écrite à la main
Quand une app que vous avez construite avec l'IA se comporte mal, la pire position est de deviner. Le bug est-il dans l'UI, la requête, l'appel API, ou les données elles-mêmes ? Sans visibilité, un correctif d'une ligne devient un après-midi de prompting spéculatif — essayer des reformulations contre une boîte noire en espérant que l'une d'elles atterrisse.
La console full-stack vous donne la visibilité que les ingénieurs attendent, à l'intérieur de Builder : logs serveur et navigateur, tables et lignes de la base de données, requêtes et réponses réseau, et erreurs avec leur contexte — tout à côté de la conversation. Vous voyez ce qui s'est réellement passé, puis mettez la preuve dans le prochain prompt.
Ce n'est pas une surface de niche pour power-users. Toute la promesse de construire du logiciel à partir du langage naturel s'effondre la première fois que quelque chose casse et que la plateforme ne peut pas vous montrer pourquoi. La visibilité est ce qui garde la promesse honnête.
Comment fonctionne la console
Tout se passe à côté de la conversation — le but est de garder la preuve et l'action au même endroit.
1. Ouvrez-la à côté du chat
Pas d'outils séparés, pas de changement de contexte. La console se place à côté de la conversation et de l'aperçu en direct.
2. Lisez les logs
Sortie serveur et navigateur de l'app en cours d'exécution, si bien que « ça n'a pas fonctionné » devient une ligne spécifique à un moment spécifique.
3. Inspectez la base de données
Regardez les vraies tables et lignes Supabase derrière l'app. Confirmez si l'enregistrement a été écrit, et avec quelles valeurs.
4. Observez le réseau
Requêtes, réponses, codes de statut et timings — particulièrement précieux quand des intégrations et API externes sont en jeu.
5. Voyez les erreurs en contexte
Les échecs apparaissent avec l'activité environnante qui les a produites, pas comme des messages nus dépouillés de leur histoire.
6. Transformez la preuve en correctif
Référencez ce que vous avez trouvé dans le prochain prompt. Pour les problèmes de production en direct, Doctor — le SRE IA en lecture seule — sonde l'app, le DNS et le CDN, diagnostique la cause racine et rédige le correctif.
Pourquoi c'est important
Prompter avec des preuves bat prompter avec des impressions. « Le POST vers /api/orders renvoie 400 et la ligne n'apparaît jamais dans la table orders » produit un correctif correct en un tour ; « le truc de commande est cassé » produit une réécriture de quelque chose qui n'a jamais été le problème. La console est ce qui rend le premier type de prompt possible pour tout le monde, pas seulement les ingénieurs.
Cela représente une grande partie de ce qui sépare l'ingénierie assistée par IA du chat plein d'espoir : le système montre son état, l'humain raisonne dessus, et le correctif est ancré dans ce que la stack a réellement fait. Au fil du temps, cela produit un codebase plus calme — moins de réécritures spéculatives, des diffs plus petits, et une équipe qui fait confiance à l'app parce qu'elle peut toujours voir à l'intérieur.
Cela change aussi qui peut supporter une application. Une agence ou une équipe d'opérations peut répondre à « qu'est-il arrivé à cette commande ? » avec des données plutôt qu'une escalade, parce que la question est inspectable au même endroit où vit l'app.
Qui utilise la console full-stack
La console sert tous ceux qui ont déjà dû répondre à la question « qu'est-ce qui s'est réellement passé ? »
- Fondateurs techniques — Diagnostiquent leurs propres apps en minutes au lieu d'escalader chaque incident ou de re-prompter à l'aveugle.
- Agences — Supportent les apps clients professionnellement — reproduisent le problème, lisent la preuve, livrent le correctif revu.
- Développeurs — Vérifient le comportement backend écrit par IA — requêtes, écritures, appels API — avant de lui confier des données de production.
- Équipes d'opérations — Confirment que les flux de données entre l'app et les systèmes existants font ce que l'intégration a promis.
Notes sur la sécurité et la gouvernance
La visibilité est puissante, donc elle est livrée avec des contrôles :
- ✓ L'accès au workspace, y compris la console, suit le contrôle d'accès basé sur les rôles.
- ✓ Les correctifs pilotés par la preuve de la console passent quand même la revue Guardrails et les portes de QA avant publication.
- ✓ Security confirme les vulnérabilités contre l'app en direct avant de les signaler — des constatations, pas du bruit.
- ✓ Doctor opère en lecture seule : il sonde, diagnostique et rédige des correctifs, mais les modifications livrent via le cycle gouverné.
- ✓ Prompts, merges et déploiements autour de chaque correctif atterrissent dans l'audit trail append-only.
Ce que montre la console
Quatre surfaces couvrent la plupart des investigations de bout en bout :
| Surface | Ce que vous voyez | Ce à quoi elle répond |
|---|---|---|
| Logs | Sortie serveur et navigateur de l'app en cours d'exécution | Ce qui s'est exécuté, et ce qui a été rapporté |
| Base de données | Tables, lignes et valeurs Supabase | Les données ont-elles réellement changé, et comment |
| Réseau | Requêtes, réponses, codes de statut, timings | Ce que l'app et les systèmes externes se sont dit |
| Erreurs | Échecs avec le contexte environnant | Où ça a cassé, et ce qui y a mené |
Questions fréquentes
Ai-je besoin d'outils externes pour déboguer une app construite sur Ciao ?
Pour le travail quotidien, non — logs, base de données, réseau et erreurs sont inspectables depuis l'intérieur de Builder. Parce que l'app est du React, TypeScript et Supabase standard que vous possédez, vos ingénieurs peuvent aussi attacher tout outillage externe qu'ils préfèrent.
Puis-je regarder la vraie base de données ?
Oui. La console montre les tables et lignes Supabase derrière votre app, si bien que vous pouvez confirmer ce qu'un flux a réellement écrit. C'est souvent le moyen le plus rapide de distinguer un bug d'UI d'un bug de données.
Comment la console se rapporte-t-elle à Doctor ?
La console, c'est vous qui regardez la stack ; Doctor est un SRE IA en lecture seule qui regarde pour vous — sondant l'app en direct, le DNS et le CDN, diagnostiquant la cause racine et rédigeant le correctif. Ils fonctionnent mieux ensemble : Doctor pour les incidents de production, la console pour l'investigation au moment du build.
Qui dans l'équipe peut voir la console ?
L'accès suit le contrôle d'accès basé sur les rôles du workspace, donc vous décidez qui peut inspecter les logs et les données. Les plans enterprise ajoutent le SSO via SAML et OIDC et une MFA optionnelle par-dessus.
Utiliser la console contourne-t-il la gouvernance quand je livre un correctif ?
Non. La console informe le correctif ; le correctif merge quand même sous Guardrails avec une revue humaine enregistrée, passe les smoke gates de QA avant publication, et est enregistré dans l'audit trail append-only.