Vos automatisations low-code tombent en panne parce qu'elles sont trop intelligentes pour leurs propres biens. Une logique si alors rigide est une condamnation à mort lorsque vous êtes confronté à des incohérences de données réelles et désordonnées qui font planter vos systèmes quotidiennement. Hypothèse selon laquelle les données sont propres est le péché originel de la conception low-code. Nous avons construit tout notre monde sur le modèle si alors, mais ce modèle nécessite une certitude absolue pour fonctionner. Les données du monde réel ne sont pas certes. Elles contiennent des fautes de frappe. Elles manquent de contexte. C'est un flux chaotique d'erreurs humaines. Lorsqu'un système déterministe atteint une variation de 1%, il ne plie pas et ne s'adapte certainement pas. Et se casse tout simplement. Cela crée le piège de la fragilité, où votre automatisation n'est aussi solide que vos points de données les plus propres.

Dans l'entreprise, c'est une barre très basse à fixer pour réussir. Mais le problème ne vient pas des données, mais du modèle que nous utilisons pour les traiter. La mort du déterministe La logique déterministe est une relique de l'air, des données structurées. Cela fonctionnait lorsque tout résidait dans une table SQL et lorsque nous forcions les humains à s'adapter à des cases prédéfinies. Mais ce monde est révolu. Aujourd'hui, 80% des données d'entreprise ne sont pas structurées, ce qui signifie qu'elles résident dans des emails, des chats et des enregistrements vocaux. Les flux Power Automate traditionnels traitent les pommes et 4 PPL3 comme deux univers différents comme deux. Pour un système binaire, ce sont des chaînes de caractère totalement indépendantes. Nous avons atteint un point de rupture où le coût du nettoyage manuel des données dépasse désormais la valeur de l'automatisation elle-même.

Si vous devez passer deux heures à corriger un fichier CSV juste pour qu'un flux puisse s'exécuter pendant cinq secondes, vous n'avez en réalité rien automatisé. Vous avez juste déplacé la main d'œuvre. L'IA n'est pas juste une nouvelle fonctionnalité brillante que nous collons sur le côté de Power Platform. C'est un changement fondamental de la correspondance exacte à la similarité. L'ancien modèle demande. SA. Le nouveau modèle demande. A quel point cela ressemble-t-il à A. Pensez à la façon dont vous naviguez dans votre boîte de réception. Vous n'exécutez pas une expression régulière dans votre tête pour trouver une facture. Vous recherchez des modèles. Vous recherchez le contexte. Vous reconnaissez que INV202 et le numéro de facture 202 sont identiques même si les caractères ne correspondent pas. Les systèmes déterministes ne peuvent pas faire cela. Ils sont aveugles à l'intention. Ils ne voient que la syntaxe.

Et à mesure que nous approchons de 2026, la syntaxe devient moins importante que la sémantique. Nous assistons à une explosion massive du volume de données provenant des capteurs IoT, des flux en temps réel et des résumés générés par LLM. Si vous essayez de gérer ce volume avec des branches si alors codées en dur, votre logique deviendra un labyrinthe. Vous retrouverez avec des flux comportant 50 conditions imbriquées et ils seront toujours interrompus dès qu'un fournisseur modifiera sa signature électronique. Le modèle si alors suppose un monde parfait où l'entrée correspondra toujours au schéma. Mais en réalité, c'est l'inverse. Les données sont invariables. La logique devrait être la constante, mais notre logique est trop rigide pour survivre au contact avec la réalité. Nous avons construit des maisons de verre dans un monde où il grêle en permanence. C'est nous, nous. Demandons ensuite pourquoi le sol est couvert d'éclats.

Le passage à la conception probabiliste consiste à construire avec du caoutchouc plutôt qu'avec du verre. Il s'agit de créer des systèmes capables d'absorber l'impact d'une faute de frappe sans se briser. Nous nous éloignons de l'idée selon laquelle un système doit être à 100% correct ou à 100% correctaire dans le monde réel. Rien n'est sûr à 100%. Nous nous mentons à nous-mêmes sur la qualité de nos données depuis des décennies. Nous avons construit des salles blanches pour notre logique, puis nous avons fait semblant d'être surpris lorsque les données celles de l'équipe de vente ont provoqué une défaillance à l'échelle du système. La mort du déterminisme est la mort de ce mensonge. C'est l'aveu que nous ne pouvons pas contrôler les données d'entrée, nous devons donc moderniser le traitement. Nous entrons dans l'ère de l'entreprise approximative, où nous acceptons qu'il vaut mieux être suffisamment proche que complètement faux, faux.

Car un système capable de traiter une correspondance à 90% a infiniment plus de valeur qu'un système qui rejette tout sauf une correspondance à 100%. Il ne s'agit pas seulement d'un changement technique, mais aussi psychologique. Vous devez vous habituer à l'idée que votre système puisse être assez sûr d'une donnée. Vous devez apprendre à concevoir, en fonction du doute, car le doute est la seule manière honnête de gérer les informations non structurées. Ce changement nous oblige à passer des déclencheurs binaires à quelque chose de beaucoup plus nuancé. Le score de confiance, l'architecture de l'incertitude. Si nous acceptons que l'ère de la logique binaire est révolue, nous devons la remplacer par un nouveau cadre. J'appelle cela le modèle de l'Orchestre Symphonie. Dans une architecture informatique traditionnelle, tout le monde est un soliste jouant sur une partition rigide. Et si une personne rate une seule note, toute la performance s'arrête.

Mais dans une architecture probabiliste, nous avons des chefs d'orchestre déterministes qui gèrent des musiciens probabilistes. Le chef d'orchestre a votre flux d'automatisation de puissance. Il fournit la structure, il donne le tempo et il définit les limites. Les musiciens sont les modèles d'IA. Ils sont talentueux, mais ils sont expressifs. Et ils n'atteignent pas toujours la même fréquence à chaque fois qu'ils jouent. Le travail du chef d'orchestre n'est pas de forcer les musiciens à être des robots. Il est de les écouter et de décider si le son qu'ils produisent est suffisamment bon pour continuer. Cela nous amène au pilier central de la conception moderne, le score de confiance. Un score de confiance est une valeur de 0 à 1 qui quantifie le doute. C'est la manière dont le modèle dit, je pense que cela correspond, et voici combien je suis prêt à parier là-dessus. Dans l'ancien monde, nous avions des chemins codés en dur.

Si l'objet de l'email contient une facture, enregistrez la pièce jointe. Dans le nouveau monde, nous utilisons un routage basé sur la confiance. Nous rendons le doute interne du modèle visible pour le système. Nous ne traitons plus l'IA comme une boîte noire, mais plutôt comme un témoin doté d'un niveau de crédibilité spécifique. Voici comment vous construisez cela dans Power Platform. Lorsque vous utilisez AI Builder ou Azure AI, vous n'obtenez pas seulement les données extraites. Vous obtenez une couche de métadonnées qui révèle la probabilité pour chaque champ. Si le modèle extrait un montant total de 1,500 dollars, il vous indique également qu'il est sûr à 95 francs de ce chiffre. En tant qu'architecte, vous disposez désormais de trois zones d'action distinctes. Premièrement, la zone verte. La confiance est de 0,90 ou plus. Le risque d'erreur est faible, le coût d'une erreur est gérable et le résultat est que vous automatisez.

Le système fonctionne sans intervention humaine. Deuxièmement, la zone jaune. La confiance est comprise entre 0,60 et 0,89. Le modèle est assez sûr, mais il n'est pas certain. Le document était peut-être légèrement flou ou l'écriture manuscrite était peut-être désordonnée. Dans cette zone, vous signalez. Le système achemine les données vers un réviseur humain pour une vérification rapide. Troisièmement, la zone rouge. La confiance est inférieure à 0,60. Le modèle est en train de deviner. Dans cette zone, vous rejetez ou faites remonter. Vous ne laissez pas ces données à proximité de votre base de données de production. Il s'agit d'une couche transparente de gestion des risques. Cela vous permet de faire évoluer votre automatisation tout en maintenant une soupape de sécurité. Pensez aux implications pour la gouvernance. Dans un système déterministe, les erreurs sont silencieuses. Un flux s'exécute, il choisit le mauvais numéro à cause d'une faute de frappe et il écrit ce mauvais numéro dans votre ERP.

Vous ne le découvrez qu'à la fin du trimestre. Dans un système probabiliste, l'erreur a une signature. Le système sait qu'il a des difficultés et il vous dit « Hey, j'ai traité cela, mais ma confiance n'était que de 62%. » C'est un signal incroyablement puissant. Cela vous permet de créer un tableau de bordé d'eau. Vous pouvez voir exactement où vos modèles échouent. Vous pouvez voir quels fournisseurs envoient des documents que l'IA ne peut pas lire et voir quelles étapes du processus atteignent systématiquement la zone jaune. Vous ne créez pas seulement un flux, vous créez une boucle d'intelligence. C'est là qu'Azure AI et AI Builder brillent vraiment. Ils exposent ces scores à un niveau granulaire, ce qui vous permet de voir la confiance pour un tableau, une cellule ou une intention spécifique. Vous pouvez même utiliser Power Effects pour créer des seuils dynamiques. Peut-être que pour une note de frais de 50 dollars, une confiance de 0,70 est suffisante.

Mais pour un bond de commande de 50 000 dollars, vous voulez une confiance de 0,98 à… Vous alignez enfin votre logique technique avec votre risque commercial. Nous avons traité chaque point de données comme s'il avait le même poids, mais ce n'est pas le cas, mais ce n'est pas le cas. La conception probabiliste vous permet de traiter une décision à enjeu élevée différemment d'une décision à faibles enjeux, même au sein du même flux. Vous ne construisez plus pour un monde parfait, vous construisez. Pour un monde où vous savez exactement quel degré d'incertitude, vous êtes prêt à tolérer. Une fois que vous maîtrisez le score, vous pouvez commencer à examiner la logique qui comble les lacunes. Correspondance floue et logique sémantique. Mais comment gérons-nous réellement les données qui se situent dans ce juste milieu d'incertitude ? Commençons par admettre que la correspondance exacte échoue.

Elle échoue parce qu'elle manque de contexte. Dans l'ancien modèle, si le nom d'un fournisseur était erroné d'un seul point, la recherche échouait. La recherche ne tient pas compte de votre intention. Elle ne s'intéresse qu'aux valeurs astis. C'est là qu'intervient la correspondance floue. Il s'agit d'une technique qui identifie et relie des enregistrements non identiques en calculant un score de similarité et qui sert de pont entre IBM et IBM. Et l'impact n'est pas théorique. Les recherches montrent que la mise en œuvre de la correspondance floue peut améliorer vos taux de correspondance jusqu'à 2400. Cela représente 2400 de vos données qui auraient auparavant été rejetées ou envoyées à un humain pour correction manuelle. Dans un environnement à volume élevé, cela représente des milliers d'heures de temps récupérées. Mais vous devez comprendre les mécanismes. Il existe deux manières principales d'envisager cela.

Premièrement, la logique basée sur les caractères. C'est ce qu'on appelle souvent la distance de Levenstein. Elle compte le nombre de modifications nécessaires pour transformer une chaîne en une autre. C'est parfait pour les fautes de frappe. Si quelqu'un écrit écran manager uge au lieu de management uge, le système voit les E et A manquants. Il calcule la distance et constate qu'ils sont presque identiques. Deuxièmement, nous avons la logique sémantique. C'est là que les choses deviennent intéressantes. La logique sémantique ne se soucie pas de l'orthographe. Elle se soucie du sens. Si un système dit client et un autre dit client, une correspondance basée sur les caractères échouera à chaque fois. Mais un modèle sémantique, c'est qu'il s'agit de la même chose. C'est le passage de la correspondance de caractères à la correspondance de concepts. Lorsque vous combinez des scores de confiance avec la correspondance floue, vous créez un système capable de naviguer dans la réalité désordonnée des données commerciales.

Vous n'êtes plus limité par des règles rigides qui s'effondrent dès qu'un humain fait une faute de frappe. Vous construisez un système qui comprend les nuances. C'est ainsi que vous passez de la simple automatisation à une véritable intelligence numérique, en créant des flux de travail, autocorrecteurs. Même avec la meilleure correspondance floue au monde, nous devons faire face à la réalité. L'IA continue d'halluciner. C'est simplement la façon dont la technologie fonctionne actuellement. Les données actuelles montrent que même les modèles les plus avancés ont des taux d'hallucination compris entre 15 et 20%. Si vous construisez des systèmes pour une entreprise, vous ne pouvez pas ignorer un taux d'échec d'un sur cinq, et vous ne pouvez certainement pas vous en sortir en vous contentant d'une ingénierie rapide. Il faut accepter qu'atteindre un taux d'hallucination de 0% n'est pas un tour de magie.

C'est un choix architectural délibéré. C'est là que nous allons au-delà de la simple automatisation et commençons à créer des flux de travail autocorrecteurs résilients. Pour ce faire, nous utilisons une structure que j'appelle le modèle de validation à double chemin. Il agit comme une protection qui empêche l'imagination créative de l'IA de perturber vos données réelles. Il existe une règle fondamentale pour l'architecte moderne. Ne laissez jamais un grand modèle linguistique faire le calcul. Les LLM sont des moteurs de raisonnement souples, ce qui les rend très efficaces pour comprendre l'intention ou trouver un détail spécifique dans une pile de textes désordonnée. Cependant, ils ne sont pas fiables d'un point de vue statistique lorsqu'il s'agit d'arithmétique de base. Si vous demandez à une IA d'extraire trois éléments d'une facture et de calculer le total, vous demandez en gros au système de tomber en panne.

Dans une conception autocorrectrice, vous utilisez le LLM pour la partie raisonnement souple comme extraire les données d'un PDF désordonné. Une fois que vous avez ces chiffres, vous les transmettez à un système déterministe pour gérer les contraintes strictes. Votre flux Power Automate ou un moteur de règles de base devrait être celui qui effectue l'addition. Il devrait être celui qui vérifie la taxe ou la conversion de devise. Si le LLM indique que le total est de 500$, mais que vos calculs indiquent qu'il devrait être de 480$, le système a détecté une hallucination en temps réel. Au lieu de planter, le système déclenche un chemin de récupération. Il peut essayer une invite différente ou signaler l'erreur pour qu'une personne puisse l'examiner. C'est la différence entre un flux qui s'interrompt et un flux qui se répare, lui-même. Nous observons les mêmes changements dans l'automatisation des processus robotiques.

La RPA traditionnelle est très fragile car elle dépend de coordonnées exactes sur un écran. Si un bouton se déplace de seulement 3 pixels vers la gauche, tout le bot échoue. La RPA autoréparatrice change cela en utilisant la vision probabiliste. Le bot ne recherche plus une coordonnée de pixels spécifique. A la place, il recherche le bouton qui ressemble à une icône de sauvegarde en haut de la page. Lorsque l'interface change, le bot utilise le contexte pour s'adapter à la volée. Il reconnaît la nouvelle disposition, met à jour sa propre logique et termine la tâche. Cela crée une boucle résiliente dans laquelle le système détecte une défaillance potentielle et établit un pont vers la solution avant même qu'un utilisateur ne réalise qu'il y ait un problème. Ce changement déplace notre attention des taux de réussite vers les taux de récupération. Nous cessons d'essayer de rendre l'IA parfaite, ce qui est de toute façon impossible, et nous commençons à rendre le système inébranlable.

Il s'agit d'intégrer une couche de contrôle et d'équilibre dans chaque transaction. Vous devriez traiter l'IA comme un stagiaire rapide qui se laisse facilement distraire. Vous la laissez faire le gros du travail en lisant des milliers d'emails, mais vous ne la laissez jamais signer l'échec sans qu'un auditeur senior ne vérifie la signature, ne vérifie la signature. Dans ce cas, votre code déterministe est cet auditeur. En séparant la réflexion du calcul, vous construisez un système qui gère le désordre du langage humain tout en conservant la précision d'une montre suisse. C'est ainsi que vous faites sortir l'IA de la phase de test pour l'amener au cœur de votre activité. Vous ne faites pas confiance au modèle, faites confiance à l'architecture que vous avez construite autour d'elle. Vous créez un filet de sécurité si solide que le moindre faux pas occasionnel du modèle ne compte même pas comme une erreur.

Cela devient juste une autre partie du cycle d'autocorrection. Cela semble formidable en laboratoire, mais en production, le plus gros goulot d'étranglement n'est pas l'IA, c'est l'humain.

Nous parlons généralement de l'automatisation comme d'un simple choix entre un humain ou une machine, mais le changement d'eux. Probabilité nous oblige à trouver un juste milieu. Les références du secteur montrent une vérité assez dégrisante. Environ 50% des flux de travail d'IA nécessitent encore un expert pour les examiner avant qu'ils ne soient terminés. C'est la principale raison pour laquelle nous assistons à une crise du pilote à la production. Si vous regardez les chiffres, 88% des pilotes d'IA échouent dans l'année. Ils n'échouent pas parce que la technologie est défaillante. Ils échouent parce que les personnes qui les conçoivent essayent d'automatiser 100% de la tâche beaucoup trop tôt. Trop. Ils ont construit un système qui fonctionne sur des données de tests propres, mais la logique s'est fondée dès qu'elle rencontre les frictions d'un vrai service. Lorsque vous ignorez l'élément humain, vous créez une charge de vérification.

Si votre IA économise 10 minutes de saisie de données, mais ajoute 50 minutes de vérification du travail parce que l'équipe ne lui fait pas confiance, vous avez en réalité perdu en productivité. Vous avez créé un passif au lieu d'un atout. Conception réussie en 2026 traiteront le travail de vérification comme une fonctionnalité principale. Elles ne considèrent pas la révision humaine comme un échec du système. Au contraire, elles la considèrent comme un élément nécessaire de l'architecture. Elles intègrent le coût de cette révision dans le retour sur investissement dès le premier jour. Le secret pour que cela fonctionne est une logique de révision à plusieurs niveaux. C'est ainsi que vous pouvez faire évoluer les choses sans perdre la tête. Les transactions à haut niveau de confiance se déroulent en silence. Si le modèle est sûr à 90 pics francs sans clics, les calculs sont corrects, le système avance tout simplement.

Mais les cas à faible niveau de confiance, comme la zone jaune dont nous avons parlé, déclencheront une escalade. Cela change complètement le rôle humain. Nous nous éloignons de la saisie de données pour nous tourner vers l'audit des données. Dans l'ancien modèle, l'humain était le moteur car il effectuait toutes les opérations de saisie et de clics. Dans le nouveau modèle, l'humain est le gouverneur. Il gère les exceptions et fournit les nuances qu'un modèle probabiliste ne peut pas tout à fait comprendre. Pensez à ce que cela représente pour l'équipe. Lorsque les gens savent qu'ils n'ont examiné que les 5% de cas qui sont réellement difficiles, ils restent beaucoup plus impliqués. Ils ne sont plus ennuyés par la routine. Ils sont mis au défi par la complexité des cas difficiles. Mais vous devez créer la bonne interface pour que cela fonctionne. Vous ne pouvez pas simplement envoyer un email pour dire que quelque chose est mal d'assistible.

Vous devez montrer une comparaison côte à côte. Montrez à la personne le document source. Montrez ce que l'IA extrait et mettez en évidence le champ exact ou le score de confiance à chuter. Si vous voulez évoluer, vous devez arrêter de faire comme si l'examen humain signifiait que votre automatisation est faible. C'est en fait le contraire. Un humain bien intégré est ce qui rend un système probabiliste suffisamment solide pour survivre dans le monde réel. C'est la dernière couche de votre architecture autocorrectrice. L'avenir agentique. Nous nous tournons vers un nouvel horizon appelé l'entreprise agentique. C'est le point final logique de tout ce dont nous avons parlé aujourd'hui. Nous entrons dans un monde où les agents ne sont plus de simples scripts ou flux de base car ils deviennent des travailleurs numériques de premier ordre. La Power Platform évolue sous nos yeux. Elle passe d'un créateur d'application standard à un hub d'orchestration complet.

Dans l'ancien modèle, vous créez une application spécifique pour résoudre un problème spécifique. Mais dans le modèle agentique, vous créez un environnement dans lequel les agents résolvent ces problèmes à votre place. Ces agents ne se contentent pas de suivre une liste statique d'étapes. Ils observent leur environnement, évaluent leur propre niveau de confiance et décident quel outil est réellement le bon à utiliser ensuite. D'ici 2026, la gouvernance ne ressemblera plus du tout à ce qu'elle était aidé des deux ans. Des outils tels que Purview et Sentinel évoluent vers la détection probabiliste des anomalies. Ils ne se contentent plus de rechercher un mot de passe divulgué. Au lieu de cela, ils recherchent des modèles comportementaux qui ne semblent tout simplement pas corrects. Ils appliquent la même logique de similarité que celle que nous utilisons pour l'extraction de données à la sécurité de l'ensemble de votre locataire.

Ce changement est permanent. Les personnes qui s'en tiennent à une logique rigide du type KSI alors Regmus se retrouveront à gérer des systèmes défaillants et des équipes frustrées. Elles seront coincées dans un cycle de maintenance constante tout en essayant de réparer une maison de verre qui n'a jamais été conçue pour ce genre de conditions, mais été conçue pour ce genre de conditions météorologiques. L'entreprise agentique commence par une seule réalisation. Nous n'avons pas besoin de contrôler chaque variable pour obtenir un résultat fiable. Nous devons simplement contrôler l'architecture. Notre travail consiste à définir les seuils et à mettre en place les garde-fous afin que les agents puissent travailler dans ses limites. Dans ce monde, votre logique métier devient élastique. Elle s'étend pour gérer un nouveau fournisseur ou un format de documents différent sans qu'un développeur ait besoin de réécrire une seule ligne de code.

C'est la véritable promesse du low-code. C'est la capacité d'évoluer à la vitesse de la pensée plutôt qu'à la vitesse de la syntaxe. Mais pour y parvenir, vous devez commencer dès aujourd'hui. Arrêtez de construire pour un monde parfait et commencez à construire pour le monde désordonné dans lequel nous vivons réellement. Vous devez accepter le doute. Défi des mises en œuvre. Voici vos devoirs pour la semaine. Je veux que vous trouviez votre flux d'échecs le plus élevé. Ne choisissez pas le plus complexe, mais trouvez celui qui plante le plus souvent à cause de données erronées. L'objectif n'est pas de corriger les données. Vous ne pouvez pas contrôler ce que vos utilisateurs ou vos fournisseurs décident de vous envoyer. Au lieu de lutter contre cette réalité, je veux que vous ajoutiez un seuil de confiance. Accédez à votre générateur d'IA ou à votre action LLM et exposez ce score de probabilité.

Créez une condition simple. Si le score de confiance est inférieur à 85 francs ans, ne laissez pas le flux planté. Enracinez ce cas spécifique dans un dossier de révision ou une liste SharePoint pour une vérification manuelle. Observez ce qu'il advient de votre taux de réussite. Vous verrez le stress quitter votre système dès que vous cesserez de prétendre que chaque entrée sera parfaite. Si ce changement de mentalité a changé votre approche, suivez-moi à Mircopiter sur LinkedIn. Je partage constamment des analyses approfondées de ces modèles architecturaux. Partagez-les avec votre équipe, en particulier si vos flux sont en panne en ce moment. Nous devons arrêter de construire avec du verre et commencer à construire avec intention. C'est la technique et elle réduit vos temps d'arrêt de moitié une fois que vous commencez à la pratiquer. Si vous voulez la version avancée utilisée par les pros, regardez cette vidéo.

Abonnez-vous pour plus de tutoriels. Arrêtez de lutter contre la réalité confuse de vos données et commencez plutôt à concevoir en conséquence. Lorsque vous utilisez des scores de confiance, vous transformez des flux fragiles en systèmes résilients qui fonctionnent réellement. Mais voilà le truc. Le modèle ne fonctionne que si vous le construisez correctement. Si vous voulez voir exactement comment configurer cela dans Copilot Studio, regardez cette prochaine vidéo dès maintenant. Si cela a changé votre façon de penser l'IA, suivez-moi sur LinkedIn ou abonnez-vous à Master the New Model. Un modèle.