Intégrations et automatisation opérationnelle

Dessinez le déclencheur, les entrées, les transformations, les décisions, les actions, les systèmes et les temps d'attente. Notez où se créent la valeur et les pertes de transfert.

Supprimez les étapes inutiles avant la technologie. Mesurez la variation et les exceptions ; un processus instable nécessite d'abord une standardisation ou une assistance limitée.

Choisissez ensuite le niveau de technique nécessaire. Avec un contexte source fourni manuellement, vous collez vous-même un texte approuvé dans le chat, comme la fiche de Noor. Avec le RAG (retrieval-augmented generation), un système recherche d’abord des extraits pertinents dans les sources et les utilise pour répondre ; contrôlez donc à la fois la sélection et la réponse.

Un agent peut choisir les étapes suivantes ou les outils dans les limites des autorisations accordées. MCP est un protocole permettant aux applications de proposer des outils et du contexte ; ce n’est en soi ni un agent ni une garantie de qualité. Ces concepts peuvent être combinés. Une connexion limitée à la lecture présente des risques différents de ceux d’une connexion qui envoie des messages.

• Déclencheur
• Entrée
• Décision
• Système
• Exception
• Temps d'attente

Précisez qui a accès à quelle boîte aux lettres, calendrier, dossier ou feuille. Séparez la lecture et l'écriture et définissez la correspondance des champs, la source de vérité et le comportement en cas de conflit.

Utilisez des scopes minimaux et un environnement de test. Enregistrez les actions sans contenu sensible inutile et confirmez la communication externe ou les modifications critiques.

• Système
• Identité
• Portée
• Mapping de champs
• Source de vérité
• Validation avant écriture

Utilisez une progression : informer, préparer un projet, recommander, exécuter après approbation, automatiser de manière limitée, puis agir de façon autonome dans des limites strictes. Les conséquences des erreurs, leur détectabilité et la réversibilité déterminent le niveau.

Établissez des KPI, des garde-fous et des scénarios de repli. Un pilote à faible risque réussi ne prouve pas que des actions financières ou publiques sont appropriées.

• Assistance
• Recommandation
• Approbation
• autonomie
• Garde-fous
• Solution de repli

Vérifiez d’abord les champs obligatoires, les formats, les règles métier et la version de la source. L’idempotence signifie que répéter la même action voulue ne produit pas un effet supplémentaire, comme un deuxième enregistrement. Réutilisez pour cela la même clé d’action lors d’une nouvelle tentative. L’application ou l’API destinataire doit réellement reconnaître cette clé et conserver de manière fiable le statut correspondant. Le seul fait de transmettre un numéro de commande ou d’écrire « ne pas exécuter deux fois » dans un prompt n’empêche pas une action en double.

Après un dépassement du délai d’attente, une action peut déjà avoir réussi alors que sa confirmation manque. Vérifiez le statut ou recommencez au moyen d’une idempotence dont la prise en charge est démontrée, dans la durée de validité convenue. Les systèmes suivants dans la chaîne doivent eux aussi empêcher les exécutions en double. Si cette protection manque et qu’une répétition peut causer un préjudice, arrêtez pour procéder à un contrôle. Définissez le nombre maximal de tentatives, la procédure de rétablissement et les champs d’audit nécessaires.

• Schéma
• Règle métier
• Clé unique
• Nouvelle tentative
• Quarantaine
• Compensation

Le réviseur reçoit les données sources, l'action proposée, les modifications, l'incertitude et les conséquences. Présentez uniquement les décisions significatives pour limiter la fatigue d'approbation.

Définissez les pouvoirs, les champs à confirmer et le motif du refus. Les actions critiques ne reçoivent aucune approbation tacite lorsque le délai d’attente est dépassé.

• Contexte de décision
• Modification
• Risque
• Réviseur
• Refus
• Timeout

Surveillez le volume, le succès, la latence, les catégories d'erreurs, le travail de correction, les garde-fous et les coûts. Combinez les métriques techniques et commerciales ; le vert technique peut cacher de mauvais résultats pour les clients.

Le runbook décrit le diagnostic, la pause, le basculement manuel, la communication, la récupération et la revue post-incident. Entraînez-vous avant une réelle panne.

En cas de possible violation de données personnelles : limitez immédiatement les dommages, conservez en sécurité les preuves nécessaires de l’incident et avertissez le responsable désigné. Une violation peut aussi être la perte, la modification non autorisée ou l’indisponibilité de données personnelles. Une panne ordinaire sans données personnelles affectées n’est pas automatiquement une violation de données. Consignez le moment de la prise de connaissance, les données concernées, le risque, les mesures et la décision de notification.

Le sous-traitant informe le responsable du traitement sans retard injustifié. Celui-ci évalue la notification à l’autorité de contrôle compétente : sans retard injustifié et, si possible, au plus tard 72 heures après en avoir pris connaissance, sauf si un risque pour les personnes est peu probable. N’attendez donc pas le troisième jour. En cas de risque probablement élevé, une information directe des personnes concernées peut aussi être nécessaire. Les détails manquants peuvent, si nécessaire, être complétés ultérieurement ; documentez les retards et les décisions. Vérifiez si l’APD belge est compétente, puis utilisez son portail de notification.

• Signal
• Seuil
• Alarme
• Pause
• Solution de repli
• Post-mortem