La plupart des outils de feedback vous laissent « configurer des règles » : remplir des conditions, choisir des actions, cliquer sur enregistrer. Ça marche, mais il y a un plafond — les règles sont statiques, l'activité ne cesse d'évoluer, et un processus que vous avez configuré prend vite du retard. L'un des virages différenciateurs de Loopback consiste à faire passer la « configuration » à l'« évolution » : c'est le Coding Loop (aussi appelé mode Builder).

De la « configuration de règles » à la « description d'un objectif »

Lorsque vous créez un workflow, vous n'avez pas à parcourir une pile de menus déroulants de conditions. Vous décrivez l'objectif en langage clair — par exemple, « feedback négatif lié à un remboursement → assigner à l'équipe paiements et rédiger des excuses » — et cliquez sur « Générer le brouillon » ; le brouillon apparaît dans le chat IA à droite. À partir de là, vous l'affinez dans la conversation :

  • Cliquez sur « Modifier » pour le changer en langage naturel, par exemple « compter aussi les notes inférieures à 3 étoiles ».
  • Cliquez sur « Suivant » pour passer à la revue avant mise en production.
  • Une fois validé, cliquez sur « Activer » pour le mettre en service.

Vous et l'IA écrivez ensemble une logique de traitement, vous ne remplissez pas un formulaire. C'est de là que vient le nom « Coding Loop » — itérer sur un processus comme vous itéreriez sur du code, mais en langage naturel.

Deux barrières avant la mise en production

Un processus exécute des actions automatiquement, il y a donc une revue avant sa mise en production :

  1. Vérification des dépendances : un canal que le processus doit notifier (Feishu, par exemple) n'est-il pas encore connecté ? Il vous invite à le connecter d'abord, à supprimer cette étape ou à basculer vers un canal déjà connecté.
  2. Rejeu d'impact : les actions qui s'exécuteront automatiquement (assigner / escalader / clôturer / changer la priorité) requièrent votre autorisation explicite, et vous obtenez un rejeu sur les 30 derniers jours d'historique — si ce processus avait déjà existé, combien d'éléments il aurait fait correspondre et combien d'actions il aurait déclenchées. Vous pouvez ainsi juger si la portée est raisonnable avant la mise en production.

Garde-fous stricts

« Évoluer » ne veut pas dire « automatisation laissée sans contrôle ». Le système comporte quelques contraintes qui ne peuvent jamais être franchies :

  • Pas de réponses sortantes entièrement automatiques — un brouillon de réponse doit être confirmé par un humain avant l'envoi.
  • Pas de clôture automatique d'un P0.
  • Limitez chaque processus à 1 à 4 règles ciblées ; entasser toute votre logique dans un seul processus est déconseillé.

Un processus actif peut être mis en pause / relancé à tout moment ; continuer à l'éditer crée une nouvelle version, l'ancienne est archivée automatiquement, et une seule version d'un processus donné est active à la fois.

Pourquoi les architectures traditionnelles ne comblent pas ce manque

Avant l'existence des agents de code, faire itérer un processus sur lui-même supposait soit une équipe d'ingénierie qui écrit des scripts (non réutilisables, et il faut du personnel pour cela), soit c'était tout simplement impossible. Le SaaS de ticketing traditionnel est architecturé autour de « des humains qui configurent des règles », et il ne peut pas ajouter la couche où « l'IA l'écrit pour vous et continue d'apprendre ». Le Coding Loop industrialise « la flexibilité de construire vos propres scripts » : flexible, mais sans devoir mobiliser une équipe d'ingénierie pour l'entretenir.

Les formules diffèrent par la concurrence de la boucle Builder (Pro autorise 1 exécution simultanée, Max est illimité). Le moyen le plus rapide d'en faire l'expérience est de démarrer un essai gratuit pour un essai Max de 7 jours — l'essai vous donne la boucle Builder complète. Vous pouvez aussi commencer par lire Modèles de workflow pour apprendre le chemin à partir d'un modèle.