Je commence ce mois-ci chez Nurun à Québec comme architecte logiciel senior, plus près des portails externes, services Web et intégrations .NET. Le SaaS retire une partie des serveurs de notre dessin, mais il ajoute une frontière réseau et un fournisseur dans chaque opération.

Lorsqu’un portail appelle un service SaaS, il résout le DNS, établit TLS, présente une clé ou un jeton, envoie une requête et attend une réponse limitée par un timeout. Le fournisseur valide le tenant, applique ses règles, écrit ses données et retourne un statut. Une boîte sur le diagramme cache donc un protocole complet.

Intégrer sans rendre la panne contagieuse

Prenons la création d’un prospect :

1. le portail valide et enregistre la demande localement;
2. il place un message avec un identifiant unique dans une file;
3. un worker appelle l’API SaaS;
4. un succès associe l’identifiant distant;
5. un timeout déclenche une reprise avec attente croissante;
6. un rejet fonctionnel va dans une file d’exception visible.

Cette séquence évite de perdre la demande si le SaaS est lent. L’idempotence empêche un doublon lorsque la réponse a été perdue après la création. Si l’API ne supporte aucune clé idempotente, l’intégration doit chercher l’objet avant de recréer ou tenir une table de correspondance prudente.

Les timeouts doivent être plus courts que le délai du portail. Trois reprises immédiates dans la requête utilisateur ne font qu’allonger l’attente et charger un fournisseur malade. Un disjoncteur peut interrompre temporairement les appels et laisser la file absorber la panne. Il faut surveiller l’âge du plus vieux message, pas seulement la taille de la file.

Garder la maîtrise du compte et de la donnée

Le SSO centralise l’identité, mais les rôles restent à mapper. Un groupe interne Ventes-Québec ne devrait pas devenir administrateur global par défaut. Le départ d’un employé doit retirer le compte, les sessions et les jetons d’intégration. Les comptes de service ont leur propre propriétaire et leurs clés tournent sans arrêt complet.

Le contrat doit préciser disponibilité, limites d’API, sauvegarde, notification d’incident, localisation et export. Je testerais un export incluant relations, fichiers et historique. Le format CSV d’une table principale n’est pas une sortie suffisante si le processus dépend de commentaires et de pièces jointes.

Une mise à jour SaaS peut changer un champ ou un comportement. La validation de schéma, le versionnement de l’API et un environnement de test protègent l’intégration. Si le fournisseur retourne un champ inconnu, le client devrait l’ignorer lorsque possible; s’il retire un champ requis, l’alerte doit arriver avant que la file bloque.

Réconcilier même lorsque tout semble vert

Une file vide ne prouve pas que le SaaS contient le bon résultat. Je programmerais un rapprochement qui choisit les objets modifiés, compare identifiant, version et champs critiques avec la table locale, puis classe absent, divergent ou conforme. Les divergences n’écrasent rien automatiquement lorsqu’une modification est possible des deux côtés. Elles vont vers une règle de maître ou une revue. Cette boucle détecte le message perdu, la correction manuelle et le bug de transformation que les métriques de transport ne voient pas. Un petit échantillon quotidien et un contrôle complet périodique donnent une assurance proportionnée au volume.

Dans un vrai projet, je dessinerais la frontière comme un composant à part entière : contrat, timeout, reprise, identité, observabilité et réconciliation. On ne contrôle plus le serveur, mais on doit encore contrôler la façon dont notre système dépend de lui.