Plateforme
Doctor : l'AI SRE en lecture seule pour vos apps en direct
Quand quelque chose casse en production, Doctor enquête comme un site reliability engineer — et vous remet le diagnostic et un correctif rédigé au lieu d'une page de logs.
Doctor est le site reliability engineer IA en lecture seule de Ciao. Il sonde l'application en direct, le DNS et le CDN, diagnostique la cause racine des incidents et rédige le correctif. Contrairement aux agents avec un accès en écriture à la production, Doctor est en lecture seule par conception — il peut tout regarder et ne rien changer, si bien que le diagnostic est rapide, continu et sûr à exécuter contre de vrais systèmes.
Publié 2026-07-03 · Dernière mise à jour 2026-07-03
La production casse ; l'expertise est rare
Chaque application a un jour son mauvais après-midi : le site est en panne, le checkout renvoie des erreurs, le login échoue pour un client et personne ne sait pourquoi. La réponse traditionnelle est un site reliability engineer qui fouille dans les logs, les enregistrements DNS et le comportement du CDN jusqu'à ce qu'une histoire émerge. La plupart des équipes qui construisent avec l'IA n'ont pas cette personne — et ne devraient pas avoir à en embaucher une pour garder un portail en vie.
Doctor est le SRE IA en lecture seule de Ciao. Il sonde l'application en direct, le DNS et le CDN, diagnostique la cause racine et rédige le correctif. La lecture seule est la décision de conception qui compte : Doctor peut tout regarder et ne rien changer.
Comment se déroule un diagnostic
Un diagnostic suit le même chemin qu'un SRE expérimenté prendrait — juste immédiatement, et noté.
1. Quelque chose semble anormal
Un contrôle en production échoue, un indicateur de santé passe au rouge dans Conductor, ou un humain demande à Doctor d'enquêter sur un symptôme.
2. Doctor sonde l'app en direct
Il requête de vraies routes, exerce le flux en échec et lit les réponses et erreurs comme le navigateur d'un utilisateur les rencontrerait.
3. Puis le chemin vers elle
La résolution DNS, l'état des certificats et le comportement du CDN sont aussi sondés, parce que « l'app est en panne » est souvent en réalité « la route vers l'app est en panne ».
4. Le contexte rejoint la preuve
Les déploiements récents, les changements de configuration et l'historique des contrôles resserrent quand ça a cassé et ce qui a changé autour de ce moment.
5. Une cause racine, en langage clair
Le résultat est un diagnostic, pas un déversement de logs : ce qui a cassé, où, et pourquoi — avec la preuve attachée.
6. Un correctif rédigé, par la porte d'entrée
Doctor rédige le correctif, et il livre comme toute modification livre : via Builder, la revue Guardrails là où les policies l'exigent, et les portes de QA. Le diagnostic est immédiat ; la modification reste gouvernée.
Pourquoi la lecture seule est importante
Donner à une IA un accès en écriture à la production est une décision que la plupart des équipes sécurité ne prendront pas — et Ciao ne le leur demande pas. L'autorité de Doctor est d'investigation. Cela le rend sûr à exécuter en continu contre de vrais systèmes et sûr à introduire dans des environnements réglementés : le rayon d'impact d'un mauvais diagnostic est une mauvaise phrase, pas une mauvaise modification.
Cela garde aussi les incitations honnêtes. Le correctif que Doctor rédige doit survivre à la même revue et aux mêmes tests que toute modification humaine, si bien que la vitesse n'achète jamais un contournement de la gouvernance.
Il y a aussi un effet de fleet. Parce que sonder est sûr, Doctor n'a pas à attendre qu'un humain soupçonne quelque chose — les contrôles en production et les indicateurs de santé lui remettent des symptômes en continu, sur chaque projet dans Conductor. L'enquête qui commençait autrefois quand quelqu'un se plaignait commence maintenant quand le premier contrôle échoue.
Qui utilise Doctor
Doctor change l'expérience d'incident pour quiconque en a déjà géré un.
- Fondateurs et opérateurs — La personne qui a construit l'app avec Ciao n'est rarement pas celle qui peut déboguer du DNS à minuit. Doctor est l'enquêteur qu'ils n'ont pas à devenir.
- Agences — Avec une fleet d'applications clientes dans Conductor, Doctor est le premier intervenant — le diagnostic est souvent fait avant que le client ne remarque le symptôme.
- Équipes IT et plateforme — Le triage arrive pré-enquêté : les escalades viennent avec une cause racine et des preuves au lieu d'un ticket vague.
- Ingénieurs — Ils prennent toujours la décision finale — ils partent juste d'un diagnostic plutôt que de grep.
Notes sur la sécurité et la gouvernance
- ✓ Doctor est en lecture seule par conception — il ne peut pas modifier l'application, ses données ou son infrastructure.
- ✓ Les sondes couvrent l'application en direct, le DNS et le CDN.
- ✓ Les correctifs rédigés livrent via la revue Guardrails et les portes de QA comme toute autre modification.
- ✓ Les enquêtes et constatations sont enregistrées dans l'audit trail append-only.
- ✓ Doctor travaille aux côtés de SysOps, qui gère le rollback et la réconciliation comme des opérations enregistrées.
Symptôme par symptôme
Différents symptômes, même méthode : sonder, corréler, expliquer.
| Symptôme | Ce que Doctor examine | Forme typique du diagnostic |
|---|---|---|
| Site inaccessible | Résolution DNS, certificats, statut CDN, santé de l'origine | Où la requête meurt en chemin vers l'app |
| Un flux échoue | La route, ses appels backend, les changements récents dans cette zone | La modification ou dépendance qui a cassé le flux |
| Pages lentes | Timing des réponses sur les routes et assets, comportement du CDN | Quelle couche ajoute le temps |
| Erreurs après un déploiement | Le diff du déploiement, les contrôles en échec, les erreurs d'exécution | S'il faut corriger en avant ou confier un rollback à SysOps |
Questions fréquentes
Doctor peut-il apporter des modifications à la production ?
Non. Doctor est en lecture seule par conception. Il diagnostique et rédige des correctifs, et ces correctifs sont appliqués via le pipeline gouverné normal — revue, portes de QA, puis publication. La séparation est délibérée : l'investigation ne doit jamais muter la chose investiguée.
Que peut réellement voir Doctor ?
Le comportement de l'application en direct — routes, réponses, erreurs — plus le DNS, les certificats et le comportement du CDN, et l'historique propre du projet : déploiements, changements de configuration et résultats de contrôle. Cette combinaison suffit généralement à situer une cause racine.
Comment le correctif rédigé devient-il un vrai correctif ?
Il entre dans le cycle comme toute modification : sur une branche, via la revue Guardrails là où les policies l'exigent, via les smoke gates de QA, puis publication. Si revenir en arrière est plus rapide que corriger en avant, Doctor le signale et SysOps effectue le rollback comme une opération enregistrée.
Doctor remplace-t-il une rotation d'astreinte ?
Il fait le travail d'enquête et remet aux humains un diagnostic au lieu de logs bruts. Quelqu'un décide et approuve toujours — cette personne part juste bien plus en avance, et pour beaucoup d'équipes cela change ce que l'astreinte doit être.
Doctor est-il inclus, ou un module complémentaire ?
Chaque workspace Ciao inclut l'organisation logicielle IA — CTO, Doctor, analyste QA, ingénieur Security, Coder et opérateur SysOps. Pour les programmes de production, qui démarrent à 10 000 USD par an, réservez une démo et voyez un diagnostic en direct sur un vrai incident.