En 2017, plusieurs promesses ont dû donner des résultats concrets. Power BI distribue l’analyse, la RPA agit sur les écrans et le deep learning devient accessible. WannaCry et Equifax montrent en parallèle que l’automatisation accélère aussi les mauvaises hypothèses, les vieux systèmes et la collecte excessive.

Le mécanisme commun est une chaîne de décisions. Un modèle transforme une image en score; un robot transforme un document en transaction; un dashboard transforme des lignes en indicateur. Chaque chaîne doit garder provenance, version, seuil, autorité et reprise.

Trois opérations, trois preuves

Pour un modèle :

1. données versionnées et séparées;
2. entraînement reproductible;
3. seuil choisi sur validation;
4. erreurs par classe;
5. modèle signé et surveillé.

Pour un robot :

1. dossier identifié;
2. état et point de contrôle;
3. compte limité;
4. exception métier séparée;
5. reprise idempotente.

Pour un indicateur :

1. définition et grain;
2. source d’autorité;
3. contrôles de qualité;
4. rapprochement;
5. fraîcheur affichée.

Ces preuves empêchent le mot automatique de signifier invisible. Une sortie peut être rapide et rester contestable.

Les fondations ordinaires dominent encore le risque

WannaCry a exploité des machines vulnérables et un réseau propice à la propagation. Equifax rappelle le besoin d’inventaire, correctif, segmentation, détection et minimisation. Aucun modèle avancé ne compense une application sans propriétaire ou une sauvegarde jamais restaurée.

Je veux donc relier les nouvelles capacités aux mêmes contrôles : identité forte, moindre privilège, journaux, catalogue de données et procédure de sortie. Un bot ou robot possède un compte. Un modèle possède des données sensibles. Un dashboard possède une définition qui change une décision.

Les pannes doivent être exercées. On coupe l’API pendant la RPA, change l’éclairage du modèle, retarde une source du dashboard et restaure un partage chiffré. Le système affiche un état dégradé et remet le travail dans une file connue, sans créer de doublon.

Installer une boucle de contestation

Une décision automatisée doit produire un dossier minimal : entrée utilisée, version de règle ou modèle, score, seuil, résultat et droits de la personne. L’utilisateur ou l’opérateur peut contester avec un motif; le cas passe à une revue qui confirme, corrige la source ou annule. Les corrections alimentent une file d’amélioration, jamais directement le modèle en production. Un tableau suit taux de contestation, renversement et groupes touchés. Une hausse après une nouvelle version déclenche un retour ou une analyse. Cette boucle est aussi utile pour un robot qui rejette une facture que pour un modèle qui classe une image. Elle empêche la vitesse d’automatisation de fermer le chemin de correction.

Le responsable conserve également le délai de résolution de chaque contestation.

Pour 2018, je garderais une règle simple : aucune automatisation importante sans échantillon de contrôle, métrique de dérive, propriétaire d’exception et arrêt possible. La vitesse devient une vraie capacité lorsqu’on peut expliquer exactement ce qu’elle a fait et reprendre au bon endroit.