Umbodi est un agent autonome pour la visibilité dans la recherche et les réponses IA, et il fonctionne avec GitHub. Il audite votre site, rédige le correctif et ouvre une pull request sur votre dépôt — il ne pousse jamais de modification directement sur votre site. Par défaut, vous lisez le diff et le fusionnez ; il réexplore ensuite la page pour savoir si le correctif est réellement en ligne.
Une GitHub App sur les dépôts que vous choisissez. Par défaut, rien n’est fusionné sans vous. La fusion autonome est un réglage distinct, désactivé tant que vous ne l’activez pas.
Les deux modes ouvrent la même pull request. Ils diffèrent par qui la fusionne.
Umbodi ouvre une pull request sur le dépôt que vous avez choisi. Une personne relit le diff et le fusionne. Umbodi ne pousse jamais sur votre branche par défaut, et rien n’atteint la production autrement que par votre propre déploiement.
Vous activez la fusion séparément, et elle ne prend effet que si la publication automatique et la planification sont aussi actives. Umbodi fusionne alors sa propre pull request quand vos vérifications requises passent, attend le déploiement, relit la page en ligne et annule le changement s’il n’y est pas.
Il ne fusionne ni n’annule jamais sur une preuve manquante : une vérification illisible signifie attendre, et une page inaccessible signifie réessayer, puis abandonner en le disant. Il n’écrit que des fichiers de contenu et de découvrabilité, et ne peut jamais modifier ses propres garde-fous, tests ou CI.
En mode autonome, une annulation arrive sous la forme d’un seul commit sur votre branche par défaut, qui restaure les fichiers exactement tels qu’ils étaient avant sa fusion — sans force push et sans réécriture de l’historique.
La plupart des outils s’arrêtent après la deuxième. La quatrième est celle qui prouve que le travail a été réel.
Il lit votre sitemap, explore chaque page accessible et note ce qui vous coûte de la visibilité.
Titres, descriptions, données structurées et pages entières, rédigés comme la modification de fichier elle-même. Pas une tâche à faire.
Sur le dépôt que vous avez choisi, sous forme de branche et de diff. Par défaut, vous la relisez, la fusionnez et la déployez.
Appliqué signifie qu’un robot a vu la modification sur la page en ligne. Une pull request fusionnée mais jamais déployée reste non appliquée.
Chaque extension SEO qui modifie votre site directement réclame une permission qu’aucun autre prestataire n’obtient.
Par défaut, la même relecture que toute autre modification de votre site. En mode autonome, vos vérifications requises font office de barrière : rien n’est fusionné si elles ne passent pas.
Une fusion regrettée, c’est un revert. Une écriture directe regrettée, c’est un incident, et vous l’apprenez par votre trafic.
Votre historique git dit ce qui a changé, quand et pourquoi — là où votre équipe regarde déjà, pas dans le tableau de bord d’un prestataire.
Si un relecteur ne peut pas dire à quoi sert une modification, la modification n’est pas terminée.
Une page par pull request, ou un lot de fichiers de découvrabilité — sitemap, robots.txt, llms.txt. Jamais un balayage de quarante fichiers à prendre ou à laisser en bloc.
Chaque pull request nomme les constats d’audit qu’elle traite, par code, pour qu’un relecteur vérifie le changement par rapport à ce qui a été mesuré — pas par rapport à un gain promis.
S’il n’a pas pu ouvrir la pull request, il en nomme la raison — l’app non installée sur ce dépôt, par exemple — plutôt que d’annoncer une exécution propre qui n’a rien publié.
Umbodi le fait. Il audite vos pages, écrit le correctif et ouvre une pull request sur le dépôt dont votre site est issu. Par défaut, la modification est un diff que vous relisez et fusionnez comme n’importe quel autre ; la fusion autonome est une option distincte. Umbodi n’écrit jamais directement sur votre site en production.
Umbodi s’installe comme une GitHub App sur les dépôts que vous choisissez. Il n’ouvre de pull requests que sur ces dépôts, et si l’installation cesse de couvrir un dépôt, il le nomme au lieu d’annoncer une exécution propre qui n’a rien publié.
Non. Chaque modification qu’il propose à un dépôt arrive sous forme de pull request, et par défaut rien n’est fusionné sans vous. Si vous activez séparément la fusion autonome, il ne fusionne sa propre pull request que lorsque vos vérifications requises passent, puis relit la page en ligne et annule la modification si elle n’a pas abouti. Pour les sites qui ne sont pas dans un dépôt, Umbodi prépare plutôt le bloc exact à coller.
Après le déploiement, Umbodi ré-explore la page en ligne et vérifie que le correctif est présent dans ce que reçoit un robot. Appliqué signifie qu’une nouvelle exploration l’a vu, pas qu’une tâche a renvoyé un code de succès — une pull request fusionnée mais jamais déployée reste non appliquée.
Seulement si vous l’activez. La fusion autonome est désactivée par défaut et nécessite son propre réglage, avec la publication automatique et la planification actives. Une fois activée, Umbodi fusionne quand vos vérifications requises passent, puis vérifie la page en ligne et annule si la modification n’a pas abouti. Il ne fusionne jamais sur une vérification qu’il n’a pas pu lire.
Lancez d’abord l’audit et lisez ce qu’il trouve. La pull request vient après, quand vous êtes d’accord avec lui.