Dot.Blog

Workflow IA : Pauses, Reprises et Checkpoints (+ VIDEO)

odahan@e-naxos.com — sam., 16 mai 2026 14:00:00 +0100

Microsoft Agent Framework En C# : Un Vrai Workflow Doit Pouvoir Attendre Et Reprendre. Une grande partie des démonstrations d’agents repose sur une hypothèse tacite : le monde coopère. Tout se passe dans un seul run. Les données nécessaires sont disponibles immédiatement. Aucun opérateur ne répond plus tard. Aucun système externe ne retarde la suite. Rien ne s’interrompt. Rien ne redémarre. Dans un tel décor, presque n’importe quel enchaînement paraît propre. Mais la réalité est un peu différente (on s'en doutait !)

Le problème est que ce décor parfait n’existe presque jamais en production.

Dans une application réelle, un processus peut devoir attendre une information complémentaire, dépendre d’une validation métier, traverser plusieurs écrans, survivre à une fermeture d’application ou reprendre le lendemain avec des éléments pendants. À partir de là, la question n’est plus seulement : “Le système sait-il répondre ?” La vraie question devient : “Le système sait-il continuer proprement quand le temps réel casse le flot ?”

C’est le sujet de ce billet et surtout de la nouvelle vidéo consacrée à Microsoft Agent Framework en C#.

Le vrai sujet n’est pas l’approbation humaine (HITL)

Présenter ce thème comme une simple vidéo sur la validation humaine (Human-in-the-loop) serait bien trop étroit. L’approbation n’est qu’un exemple. Le sujet réel est la continuité d’exécution.

Autrement dit : comment un workflow peut-il s’interrompre sans se dégrader, attendre sans se perdre, puis reprendre sans reconstruction artificielle du contexte ?

Cette question est beaucoup plus sérieuse qu’elle n’en a l’air. Tant qu’un système n’est capable d’exister que dans une exécution continue et sans friction, il reste proche d’une démo. Il peut être spectaculaire, mais il n’est pas encore robuste.

Un agent sans pause ni reprise est souvent simplement un système qui suppose un monde parfait.

Ce que Microsoft Agent Framework rend intéressant

L’intérêt de Microsoft Agent Framework, ici, n’est pas d’ajouter encore un peu d’“IA” à une application. Son intérêt est de fournir une structure claire pour gérer les interruptions légitimes du processus. D'ailleurs, stricto sensu, ce n'est pas MAF lui-même qui fournit ce service mais un namespace particulier de la famille des "microsoft.AI.*" dont fait partie MAF bien entendu.

La vidéo insiste donc sur une distinction que beaucoup de contenus mélangent :

la session conversationnelle ;
l’état partagé ;
le checkpoint de workflow.

Confondre ces trois notions conduit presque toujours à une architecture floue.

Une session n’est pas un checkpoint.
Un historique de messages n’est pas un instantané d’exécution.
Un objet de contexte sérialisé n’est pas une reprise de workflow au sens fort.

Le checkpoint répond à une autre exigence : capturer un état d’exécution exploitable, cohérent et reprenable. Dès que l’on comprend cette différence, on sort immédiatement du cadre “chatbot” pour entrer dans celui d’un processus durable.

La démonstration choisie : attendre une information externe

Le scénario présenté dans la vidéo évite volontairement de commencer par l’approbation humaine, parce que ce serait réducteur.

Le workflow traite d’abord une demande métier. Il détecte ensuite qu’une donnée obligatoire manque pour continuer. À ce moment-là, il émet une requête externe, se met en attente, puis reprend lorsque l’information lui est fournie.

Ce scénario est plus fort que l’exemple classique d’approbation, parce qu’il montre une mécanique générale.

Le système n’échoue pas.
Le système ne repart pas de zéro.
Le système n’invente pas une suite fictive.
Le système suspend proprement son exécution.

C’est précisément ce comportement qui distingue un enchaînement crédible d’une simple démonstration en flux continu.

Le moment décisif : Le checkpoint et le redémarrage

Le passage le plus important de la vidéo est celui où le workflow est interrompu, sauvegardé, puis repris après redémarrage.

C’est là que le spectateur comprend qu’il n’est plus devant un simple mécanisme conversationnel. Il est devant une logique de système.

Ce point mérite d’être dit clairement : relancer un traitement en espérant reconstruire le contexte n’est pas une vraie reprise. C’est une approximation. Cela peut suffire pour un prototype. Cela devient faible dès qu’il faut garantir la cohérence, auditer le chemin ou réintégrer proprement une réponse arrivée plus tard.

Le checkpoint, lui, sert précisément à ne pas tricher avec cette continuité.

Lorsque le processus redémarre, l’objectif n’est pas de rejouer artificiellement une conversation ou de recomposer à la main les conditions d’exécution. L’objectif est de reprendre le flot avec son état utile, ses attentes pendantes et sa logique d’avancement intacte.

Pourquoi ce sujet est architectural

Beaucoup de discussions autour des agents se concentrent sur le prompt, les outils, les modèles ou les performances de sortie. Tout cela compte, évidemment. Mais ces discussions passent souvent à côté de la question la plus structurante : que devient le système quand la réalité métier impose une pause ?

Si votre architecture ne sait pas gérer cela, elle reste limitée à des cas heureux.

C’est pour cette raison que la pause/reprise n’est pas un détail d’implémentation. C’est une décision d’architecture. Elle détermine si votre système est capable d’assumer des dépendances externes, des validations asynchrones, des interruptions et des reprises sans s’effondrer dans de la logique ad hoc.

Il faut néanmoins rester rigoureux : si votre besoin tient dans un simple traitement linéaire et immédiat, ajouter du checkpointing est une erreur. Vous ajouteriez de la complexité sans bénéfice réel.

Mais lorsque le processus traverse le temps, la pause/reprise cesse d’être un luxe. Elle devient une exigence.

Voir la vidéo

La vidéo est disponible ici : https://youtu.be/0Bjq7viODcY

Si vous développez en C# et que vous voulez dépasser les démos qui supposent une exécution continue, ce contenu montre le seuil suivant : celui où l’on cesse de raisonner en simple “run” pour entrer dans la continuité de workflow.

C’est aussi ce qui distingue un système qui répond d’un système qui tient.

Comprendre les Workflows (vidéo précédente)

Pour comprendre cette nouvelle vidéo il faut comprendre ce que sont les workflows... Mais vous avez de la chance, la vidéo précédente traite justement de ce que sont ces plannfications algorithmiques destinées à rendre les applications utilisant de l'IA plus robustes en allignement ave les exigences de rigueur et d'audit de tout programme pro mis en production.

Vous pouvez regarder la vidéo "IA en C# : De l’Agent au Workflow" à cette adresse : https://youtu.be/4C-AePnMiHY

Conlusion

Deux vidéos sur les workflows cela peut sembler beaucoup, mais ils sont d'une importance essentielle. Ceux qui visionneront les deux vidéos comprendront l'intérêt crucial de ces constructions algorithmiques rationnalisant l'usage des IA dans des processus métier rigoureux.

Alors pas de blabla inutile, rendez-vous tout de suite sur ma chaîne YouTube !

Stay Tuned !

Créer une API HTTP locale avec Kestrel sans ASP.NET : .NET 9 minimaliste

odahan@e-naxos.com — ven., 15 mai 2026 14:00:00 +0100

Avec .NET 9+, il est possible de créer des serveurs HTTP ultra-légers sans charger toute la stack ASP.NET. Cela permet d’intégrer une API dans une application console ou desktop (WinUI, WPF, etc.), utile pour exposer des traitements IA, des fonctions de contrôle, ou une logique métier accessible par d'autres processus.

Cet article montre comment construire une API auto-hébergée minimaliste à l’aide de Kestrel et des primitives HTTP de bas niveau.

🎯 Cas d’usage typique

Fournir une interface JSON locale à une application desktop
Interagir avec un moteur IA ou une base vectorielle depuis un front local
Ouvrir une API interne pour automatiser des tests

🚀 Projet minimal

Créez un projet console :

dotnet new console -n MinimalApiApp

Ajoutez la référence à Kestrel :

dotnet add package Microsoft.AspNetCore.Server.Kestrel

⚙️ Code complet d’un serveur HTTP en C# (sans controller, sans MVC)

using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;

Host.CreateDefaultBuilder()
    .ConfigureWebHostDefaults(webBuilder =>
    {
        webBuilder.Configure(app =>
        {
            app.Run(async context =>
            {
                if (context.Request.Path == "/hello")
                {
                    context.Response.ContentType = "application/json";
                    await context.Response.WriteAsync("{ \"message\": \"Hello from Kestrel!\" }");
                }
                else
                {
                    context.Response.StatusCode = 404;
                }
            });
        });
        webBuilder.UseUrls("http://localhost:5001");
    })
    .Build()
    .Run();

📡 Tester l’API localement

Dans un navigateur ou via curl :

curl http://localhost:5001/hello

Résultat :

{ "message": "Hello from Kestrel!" }

🧪 Ajouter une route dynamique avec un paramètre

if (context.Request.Path.StartsWithSegments("/echo", out var remaining))
{
    var message = remaining.Value.Trim('/');
    await context.Response.WriteAsync($"Echo: {message}");
}

Appel via : http://localhost:5001/echo/bonjour

🔐 Sécurité minimale : restreindre l’accès local

Dans certains cas, vous pouvez écouter uniquement sur 127.0.0.1 :

webBuilder.UseUrls("http://127.0.0.1:5001");

Cela empêche tout accès extérieur à la machine locale.

🧠 Bonnes pratiques

Toujours définir un Content-Type correct (application/json recommandé)
Protéger l’API par un token simple si exposition hors localhost
Découper le pipeline avec Map() si les routes deviennent nombreuses
Ne pas oublier .UseUrls() pour contrôler l’exposition

🔚 Conclusion

Kestrel peut parfaitement servir de micro-serveur local pour des applications .NET qui ont besoin d’un point d’entrée HTTP. En se passant d’ASP.NET MVC ou de Razor, on gagne en légèreté, en temps de démarrage et en clarté. Soyons francs, parfois, juste pour exposer une API simple, les choses devenaient plus proches de l'usine à gaz que d'une simple feature sympa. Car le modèle ASP.NET est fait pour beaucoup plus, et être obligé de le traîner avec soi et son projet pour une simple API est overkilling. Grâce à Kestrel on peut aujourd'hui penser à créer des API dans des Apps simples. Il faut y penser car la lourdeur d'antan a eu tendance à nous forcer à une sorte d'auto-censure ("surtout ne pas se lancer dans ce truc ça va me prendre trop de temps"). Il faut réapprendre à s'écouter et ne pas avoir peur d'ajouter ce type de comportement même à de petites ou moyennes applications sans peur du monstre ASP.NET :-) !

Stay Tuned !

Utiliser les générateurs de source en .NET 9 : aperçu, usages et exemples

odahan@e-naxos.com — ven., 8 mai 2026 14:00:00 +0100

Avec .NET 9, les générateurs de source (Source Generators) sont devenus un levier essentiel pour automatiser, optimiser ou fiabiliser certaines tâches à la compilation. Ils permettent d’injecter du code C# généré dynamiquement en fonction du contenu du projet, sans dépendre du runtime. Comment s'en servir ?

Dans cet article, je fais le point sur leur fonctionnement, leur intégration, et les cas d’usage réels.

🧠 Qu’est-ce qu’un générateur de source ?

Un Source Generator est une extension du compilateur Roslyn qui peut :

Analyser le code existant (syntaxique ou sémantique)
Générer du code C# (via SourceText) à inclure à la compilation
Être utilisé sans modifier manuellement le code source original

Ils n’exécutent aucun code à l’exécution (contrairement aux T4 ou à la réflexion).

📦 Exemple minimal de générateur

[Generator]
public class HelloGenerator : ISourceGenerator
{
    public void Initialize(GeneratorInitializationContext context) { }

    public void Execute(GeneratorExecutionContext context)
    {
        var source = """
        namespace AutoGenerated {
            public static class Hello {
                public static string Message => \"Hello from generated code!\";
            }
        }
        """;

        context.AddSource("hello.g.cs", SourceText.From(source, Encoding.UTF8));
    }
}

Ce générateur produit une classe statique avec une propriété. On notera que le système de génération automatique du toolkit MVVM Microsoft utilise ce type de facilité pour simplifier l'écriture du code.

🧪 Exemple complet : INotifyPropertyChanged automatique

Création de l’attribut personnalisé

[AttributeUsage(AttributeTargets.Class)]
public class AutoNotifyAttribute : Attribute { }

Classe annotée côté consommateur

[AutoNotify]
public partial class Person
{
    private string _name;
    private int _age;
}

Générateur

[Generator]
public class AutoNotifyGenerator : ISourceGenerator
{
    public void Initialize(GeneratorInitializationContext context)
    {
        context.RegisterForSyntaxNotifications(() => new AutoNotifySyntaxReceiver());
    }

    public void Execute(GeneratorExecutionContext context)
    {
        if (context.SyntaxReceiver is not AutoNotifySyntaxReceiver receiver) return;
        foreach (var classDecl in receiver.Candidates)
        {
            var model = context.Compilation.GetSemanticModel(classDecl.SyntaxTree);
            var symbol = model.GetDeclaredSymbol(classDecl);
            if (symbol is not INamedTypeSymbol namedType) continue;
            var ns = namedType.ContainingNamespace.ToDisplayString();

            var props = new StringBuilder();
            foreach (var member in namedType.GetMembers().OfType<IFieldSymbol>())
            {
                var propName = char.ToUpper(member.Name[1]) + member.Name.Substring(2);
                var type = member.Type.ToDisplayString();
                props.AppendLine($"public {type} {propName} {{ get => {member.Name}; set => SetProperty(ref {member.Name}, value); }}");
            }

            var source = $$"""
            using System.ComponentModel;

            namespace {ns}
            {
                public partial class {namedType.Name} : INotifyPropertyChanged
                {
                    public event PropertyChangedEventHandler? PropertyChanged;

                    protected bool SetProperty<T>(ref T storage, T value, [System.Runtime.CompilerServices.CallerMemberName] string? propertyName = null)
                    {
                        if (EqualityComparer<T>.Default.Equals(storage, value)) return false;
                        storage = value;
                        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
                        return true;
                    }

                    {props}
                }
            }
            """;

            context.AddSource($"{namedType.Name}.g.cs", SourceText.From(source, Encoding.UTF8));
        }
    }
}

class AutoNotifySyntaxReceiver : ISyntaxReceiver
{
    public List<ClassDeclarationSyntax> Candidates { get; } = new();

    public void OnVisitSyntaxNode(SyntaxNode syntaxNode)
    {
        if (syntaxNode is ClassDeclarationSyntax cls && cls.AttributeLists.Count > 0)
        {
            Candidates.Add(cls);
        }
    }
}

Ce générateur ajoute automatiquement l’implémentation de INotifyPropertyChanged et des propriétés publiques aux champs privés d’une classe annotée.

🔧 Mise en place dans un projet .NET

Créer un projet de type Analyzer :

dotnet new analyzer -n DemoSourceGen

Ajouter une référence au package Roslyn :

dotnet add package Microsoft.CodeAnalysis.CSharp

Compiler le générateur et référencer le .dll dans un projet consommateur :

<ItemGroup>
  <Analyzer Include="..\DemoSourceGen\bin\Debug\netstandard2.0\DemoSourceGen.dll" />
</ItemGroup>

Utiliser le code généré dans le projet :

var person = new Person { Name = "Alice", Age = 42 };
person.PropertyChanged += (s, e) => Console.WriteLine($"Changed: {e.PropertyName}");p
erson. Name = "Bob";

📚 Cas d’usage fréquents

Génération de code pour la sérialisation (Json, XML, BSON...)
Implémentation automatique d’interfaces (comme INotifyPropertyChanged)
Création de proxy statiques ou factories
Code répétitif (validation, services, mappers...)
Génération de constantes (resx, settings...)

⚠️ Limitations et points de vigilance

Pas d’accès au runtime (aucun appel File.ReadAllText, etc.)
Compilation plus longue (à équilibrer selon le nombre de fichiers générés)
Complexité croissante si mauvaise structuration

Toujours documenter ce que le générateur produit, surtout pour les équipes... (et pour soi-même car revenir un an après sur un code qu'on a écrit est parfois aussi nébuleux que de regarder le code d'un autre si tout n'a pas été fait dans les règles et documenté !).

🧩 Environnement et outils

Compatible avec Visual Studio, Rider, VS Code (IntelliSense fonctionne sur le code généré)
Diagnostic via GeneratorExecutionContext.ReportDiagnostic
Débogage possible via Debugger.Launch() dans Execute()

🔚 Conclusion

Les générateurs de source en .NET 9 permettent d’automatiser des pans entiers de code répétitif ou optimisé. Ils favorisent la maintenabilité, la performance et l’évolution de vos architectures.

Stay Tuned !