Nous avons construit notre intégration ConnectWise Manage de zéro. Voici pourquoi.

L’intégration qui « fonctionne » et l’intégration qui fonctionne

Il y a deux types d’intégrations, et la plupart des plateformes ne les distinguent pas clairement.

Celle qui enveloppe les appels API. La plateforme expose des outils HTTP : GET /v2/tickets, POST /v2/tickets, PATCH /v2/agreements/{id}. L’utilisateur (ou l’IA de l’utilisateur) trouve la bonne séquence d’appels. Authentification, pagination et limitation de débit sont le problème de l’utilisateur. Si l’API a des concepts spécifiques aux MSP comme « Agreement » qui ne sont pas des types « record » génériques, l’intégration ne le sait pas et ne s’en soucie pas.

Celle qui parle le métier. La plateforme comprend qu’un Agreement ConnectWise n’est pas qu’un record — c’est une structure de facturation qui détermine si les entrées de temps comptent vers un forfait ou sont facturées en T&M. Elle comprend qu’une Configuration n’est pas juste un objet CRUD — c’est l’inventaire des actifs clients suivis par le MSP, alimenté par le RMM, que l’IA de triage doit lire pour générer des réponses contextuelles. Elle comprend que les écritures en masse de temps de ticket ne sont pas « POST le même endpoint N fois » — c’est une opération transactionnelle unique qui empêche la double facturation en cas de retry.

Pour ConnectWise Manage, nous avons construit la deuxième.

Ce que les MSP font vraiment avec ConnectWise

Avant d’écrire une ligne de code, nous avons interviewé 14 petits MSP (4 à 25 techniciens) sur ce qu’ils font réellement dans ConnectWise une journée type. Le schéma était constant :

1. Trier les tickets entrants. Le service desk lit le ticket, attribue la priorité, route vers le bon board. Besoins : lire le ticket, lire les Configurations du client (pour que l’IA puisse rédiger des réponses contextuelles), lire l’Agreement (pour que l’IA connaisse le palier SLA), écrire une note interne avec la réponse rédigée pour révision par un technicien.

2. Saisir le temps sur les tickets. Les techniciens passent la fin de chaque journée (ou le vendredi après-midi) à écrire des entrées de temps. Un technicien peut avoir 30 à 50 entrées réparties sur 15 tickets. La saisie, c’est le travail. Besoins : écriture en masse des entrées de temps avec sémantique transactionnelle pour qu’un retry ne double pas la saisie.

3. Réconcilier temps facturable vs. forfait. La même entrée de temps veut dire des choses différentes contre un Agreement T&M vs. un Agreement forfait. Besoins : lire les Agreements et les utiliser pour classer les entrées de temps au moment de l’écriture.

4. Maintenir les Configurations en phase. RMM et outils de monitoring génèrent en permanence des mises à jour de Configuration. Les ingérer dans ConnectWise sans créer de doublons ni écraser les notes saisies par l’utilisateur est une irritation mineure et constante. Besoins : déduplication au niveau intégration, pas « chaque flux a sa propre logique de dédup ».

5. Générer des paquets QBR / revue client. Mensuellement ou trimestriellement, extraire les détails d’Agreement, l’inventaire des Configurations, le résumé des tickets, la performance SLA. Besoins : lire tout cela de manière structurée pour qu’une IA puisse résumer.

Aucun de ces points n’est « écrire du CRUD générique contre un endpoint REST ». Tous dépendent du fait que l’intégration comprenne les concepts métier.

Ce que nous avons construit

L’intégration livre ces surfaces de premier rang :

Configurations

Lire et mettre à jour les Configurations ConnectWise comme des objets structurés, pas des blobs JSON. Quand un RMM pousse une mise à jour de Configuration (inventaire logiciel, changement matériel, statut de patch), l’intégration :

• Déduplique contre les Configurations existantes pour le même client + actif
• Préserve les notes saisies par l’utilisateur qui ne sont pas couvertes par le flux
• Écrit une mise à jour transactionnelle unique, pas N mises à jour partielles

Quand l’IA rédige une réponse à un ticket, elle peut lire les Configurations pertinentes via un outil structuré — pas en scrappant l’UI ConnectWise ou en parsant des réponses d’API.

Agreements

Lire et raisonner sur les Agreements au niveau métier. Un Agreement a :

• Un modèle de facturation (forfait, T&M, prix fixe, basé sur ticket)
• Une couverture incluse (quels service boards, quelles configurations, quels types de travail)
• Un palier SLA (temps de réponse, temps de résolution)
• Des tables de taux (type de technicien → taux facturable)

L’intégration expose tout cela à l’IA et aux opérateurs sous forme de données structurées. Quand l’IA d’un MSP génère une réponse à un ticket, elle sait si le client est sous SLA « Gold » ou « Bronze » et rédige en conséquence.

Opérations en masse sur le temps de ticket

La fonctionnalité rentable pour les techniciens qui perdent 30 minutes par jour à saisir du temps.

• Écriture en masse — soumettre 50 entrées de temps pour la journée d’un technicien en une seule opération
• Transactionnelle — si une entrée échoue, le batch est rollback proprement (pas d’état partiel à moitié écrit)
• Déduplication — si l’opérateur retrie suite à un timeout, la seconde tentative détecte l’état partiel de la première et le complète au lieu de doubler la saisie
• Marquage assistance IA — les entrées de temps écrites par l’IA portent un préfixe [AI-Assisted] visible. Le MSP choisit de le divulguer ou non au client sur les factures, mais la piste d’audit est toujours là.

Limitation de débit et retry

ConnectWise Manage a des limites de débit API par client qui varient selon le palier de licence. L’intégration :

• Respecte la limite par client comme un concept de premier rang, pas « réessayer sur 429 »
• Utilise un token bucket par tenant client, pas un compteur global
• Implémente des retries idempotents avec une clé de dédup dérivée du payload de requête — pour qu’un retry dû à un souci réseau n’écrive pas deux fois

Isolation cross-compte

L’intégration est livrée avec une suite de tests de sécurité cross-compte qui vérifie spécifiquement : une action scopée au Client A ne peut pas lire ou écrire les données du Client B, même si les clés API utilisées ont un accès plus large. La suite de tests fait partie de notre CI et bloque toute régression.

C’est la fonctionnalité qui intéresse l’auditeur. Quand la conformité SOC 2 ou HIPAA est en jeu, « nous avons testé que l’isolation tenant fonctionne » fait la différence entre un audit propre et un finding.

Ce que l’IA voit

L’intégration est exposée à la couche IA de JieGou via des outils MCP structurés. Une recette ou un workflow qui gère le triage de tickets peut :

read_configurations(client_tenant: "Acme Corp", filter: { active: true })
  → retourne une liste structurée de Configurations

read_agreement(client_tenant: "Acme Corp", agreement_id: "AGR-123")
  → retourne un Agreement structuré avec modèle de facturation + palier SLA

draft_ticket_response(ticket_id: "T-456", context: { configurations, agreement })
  → l'IA génère une réponse consciente du contexte spécifique du client

submit_for_approval(draft, action: "post_to_ticket_notes")
  → entre dans la file d'approbation en mode ombre

[l'opérateur relit et approuve]

write_time_entry(ticket_id, hours, description, billable: from_agreement_rules)
  → écriture transactionnelle via l'intégration

L’IA n’a pas besoin de savoir que l’API HTTP de ConnectWise existe. Elle compose des actions métier. L’intégration traduit.

Ce qu’il a fallu pour construire ça

Plus qu’un wrapper REST, moins qu’un PSA de zéro. Côté calendrier, à peu près deux sprints d’ingénierie focalisés spécifiquement sur la sémantique ConnectWise, plus du raffinement continu à mesure que les MSP pilotes font remonter des cas limites.

L’alternative — un wrapper API générique — aurait pris un sprint. Elle aurait marché pour le chemin nominal. Elle aurait échoué pour le cas du temps en masse, le cas du dédup de retry, le cas de la lecture de taux d’Agreement, et le cas de l’isolation tenant vérifiée.

Pour un vertical comme les MSP où la profondeur d’intégration PSA est le critère d’achat, un sprint de travail d’intégration supplémentaire est le bon arbitrage.

La suite

Dans la roadmap actuelle :

• Intégration ConnectWise Automate — le côté RMM de la suite CW ; même modèle de gouvernance
• Reporting ConnectWise PSA — miroir de la structure de rapports que les MSP attendent déjà de CW, généré par IA selon un planning
• Intégration Autotask PSA — l’autre grand PSA, même schéma de surfaces de premier rang

Si vous êtes un MSP utilisant ConnectWise Manage et que notre approche vous parle, réservez une démo et nous ferons une démo live de l’intégration. Si vous êtes sur un autre PSA et voulez cette profondeur d’intégration avec votre outillage, dites-le-nous — la roadmap répond aux MSP nommément.