Ce que Rewst fait bien
Commençons par le steelman. Rewst résout un vrai problème. Avant Rewst (et Liongard, et quelques outils similaires), les MSP avaient deux mauvaises options pour l’automatisation PowerShell multi-tenant : se connecter à chaque tenant client individuellement et exécuter les scripts localement, ou bâtir une orchestration maison avec des comptes de service et un scheduler. Les deux passent mal à l’échelle.
Rewst a productisé le schéma « exécuter du PowerShell sur N tenants clients depuis un seul plan de contrôle ». Il est bon pour ça. Les MSP qui l’adoptent économisent de vraies heures par semaine sur les actions répétables — provisionnement d’utilisateurs, attribution de licences, gestion de groupes, configuration de boîtes aux lettres.
Nous ne prétendons pas que Rewst est un mauvais produit. Nous prétendons qu’il est conçu autour du mauvais axe.
Ce que les architectures script-first ratent
Un script PowerShell est un artefact d’exécution. On lit le code, on l’exécute, on obtient une sortie.
Mais un script qui ajoute un utilisateur à un groupe Global Admin n’est pas que du code. C’est un événement d’autorisation qu’un auditeur voudra reconstituer deux ans plus tard. Un script qui réinitialise le mot de passe d’un utilisateur et l’envoie à une adresse de secours n’est pas que du code — c’est un événement de conformité, potentiellement un événement de conservation légale, potentiellement un événement de confiance client si la mauvaise adresse a été choisie.
Les plateformes d’automatisation script-first traitent le script comme l’artefact principal et la gouvernance comme des métadonnées ajoutées après coup. Les logs d’exécution existent ; les workflows d’approbation existent ; les fonctions de caviardage existent. Mais elles sont composées par-dessus, dans la couche opérationnelle du MSP, pas intégrées nativement.
Ce qui cloche en pratique :
- La couche d’approbation est au niveau workflow, pas au niveau action. Une fois le workflow lancé, les actions individuelles à l’intérieur s’exécutent sans review par action. Acceptable pour des resets de mots de passe en masse lors d’un événement connu sûr. Moins acceptable si le workflow était faux dans l’une de ses branches.
- Les sorties sensibles dans les logs sont le problème du MSP. Jetons de comptes de service, codes de récupération à usage unique, mots de passe générés — si le PowerShell les émet sur stdout, ils finissent dans le log d’exécution. Les caviarder est une étape de nettoyage, pas une préoccupation de pipeline de premier rang.
- L’histoire d’audit est centrée exécution, pas centrée changement. « Quel PowerShell a tourné contre ce tenant client ce jour-là ? » est répondable. « Qui a autorisé le changement de privilège sur l’utilisateur X à 15h47 ? » est parfois répondable, parfois non — parce que l’autorisation peut avoir été un résultat implicite de la configuration du workflow, pas un événement discret.
Ce ne sont pas des plaintes hypothétiques. Ce sont les questions d’audit précises que posent les relecteurs SOC 2, les assesseurs CMMC et les auditeurs HIPAA aux MSP qui construisent leurs opérations sur des scripts d’automatisation.
Gouvernance d’abord : ce qui change
La couche d’automatisation de JieGou part d’une prémisse différente : le tenant client est une frontière de gouvernance, et chaque action qui la franchit est un événement révisable.
Les conséquences :
-
Approbation par action, pas par workflow. Un job qui « réinitialise le mot de passe du CEO et l’envoie à son adresse de récupération » est un événement révisable unique. L’approbateur voit le PowerShell rendu, le tenant cible, le rayon d’impact de l’action, avant approbation. L’approbation par workflow (le modèle Rewst/Liongard) confond le point de review avec le point de composition — vous approuvez une fois « ce workflow a l’air ok », puis toutes ses branches s’exécutent.
-
Le mode ombre est un palier de premier rang, pas une variante de workflow. Toute action peut s’exécuter en mode ombre : le PowerShell est préparé, les entrées sont résolues, la sortie est simulée sans appeler Microsoft Graph / Exchange / etc. L’opérateur MSP voit exactement ce qui se serait passé. Ensuite seulement on promeut en live.
-
Le caviardage des sorties est intégré au pipeline du runner. Le runner PowerShell capture stdout/stderr, les fait passer par une passe de caviardage (supprimant les chaînes ressemblant à des jetons, à des mots de passe et à d’autres formes sensibles), et ne stocke que la version caviardée dans le log d’audit. L’opérateur voit la version caviardée dans l’UI. La sortie brute n’est jamais persistée.
-
Les actions générées par l’IA partagent le pipeline. C’est la différence architecturale significative. Quand un brouillon d’IA est préparé — que ce soit un snippet PowerShell, une réponse à un ticket ou une écriture de temps — il entre dans la même file d’approbation que les actions initiées par des humains. L’opérateur MSP n’a pas besoin de gouverner séparément « ce que l’IA a fait » et « ce que les scripts ont fait ». C’est une seule file.
-
L’override d’urgence est audité, pas non documenté. Parfois une panne ne peut pas attendre. Les rôles Owner et Admin peuvent outrepasser une approbation en attente en fournissant une raison. L’action d’override, la raison, l’identité de l’approbateur et la demande originale sont toutes conservées. L’override existe pour les urgences, pas comme raccourci.
À quoi ça ressemble en face-à-face
Nous avons publié une comparaison fonctionnalité par fonctionnalité sur la page PowerShell Automation. Pour résumer la ligne la plus importante :
Approbation par action. Rewst : au niveau workflow seulement ; une fois le flux lancé, les actions individuelles partent sans review par action. JieGou : au niveau action individuelle — approuver ou rejeter chaque changement, avec le PowerShell rendu visible.
On peut plisser les yeux et prétendre que c’est la même chose si on conçoit ses workflows en branches d’action unique. D’accord. Mais les workflows ne restent pas aussi nets dans un MSP à 20 clients, et la pression pour composer de plus gros workflows croît avec l’échelle. L’approbation par action garde l’unité révisable à la bonne granularité.
Quand Rewst reste le bon choix
Nous essayons de ne pas prétendre que JieGou convient à tous les MSP. Les cas où Rewst reste mieux adapté :
- Vous avez déjà standardisé votre bibliothèque d’automatisation dans Rewst et votre équipe a un an de mémoire musculaire. Le coût de changement est réel.
- La proposition de valeur de votre MSP est « nous automatisons agressivement, la gouvernance est secondaire ». C’est un positionnement défendable. JieGou est pour les MSP qui veulent une gouvernance de premier rang.
- Vous avez besoin d’une intégration native Rewst spécifique que nous ne livrons pas. Nous couvrons les intégrations MSP courantes (ConnectWise Manage, Microsoft Graph, Exchange, Intune, Azure AD), mais Rewst a un catalogue plus profond sur certaines niches.
Où nous pensons que le marché va
Le canal MSP est à 18 mois dans la conversation « IA pour MSP ». Deux choses ont bougé :
-
Les acheteurs conformité (MSP avec clauses MSA exigeant des preuves SOC 2) veulent une automatisation native à la gouvernance. Pas « nous ajoutons la gouvernance par-dessus ». Ils veulent que la plateforme achetée pour les opérations MSP soit la plateforme qui répond aux questions de l’auditeur — même log d’audit, même trace d’approbation, même caviardage.
-
Les actions assistées par IA ne sont plus séparées des actions scriptées au sens opérationnel. Si la couche IA de votre MSP rédige une réponse à un ticket et que la couche d’automatisation de votre MSP écrit le temps dans le ticket, et que les deux transitent par le même tenant client, ils veulent être un seul pipeline. Pas deux pipelines à réconcilier.
JieGou est construit pour ces deux bascules du marché. Rewst ne l’est pas — by design. Cela ne rend pas Rewst faux. Cela en fait un produit différent pour un MSP différent.
Si ce MSP différent, c’est vous, vous devriez continuer avec Rewst et le reste de cet article n’est pas pour vous.
Si vous êtes le MSP qui veut des opérations nativement gouvernées, nativement IA, nativement auditées — nous serons ravis de vous montrer le pipeline de bout en bout. Réserver une démo ou passer l’audit opérationnel pour voir où vos écarts actuels vont vous coûter.