Top AI Repo GitHub 2026 : explication détaillée avec exemple

1. Vue d’ensemble

En 2026, le classement des dépôts tendance sur GitHub est dominé par un seul mot-clé : agent. Il n’y a plus de « chatbot qui répond une question et c’est tout », ces dépôts construisent des systèmes d’IA capables de faire leurs propres plans, d’appeler des outils (tools), de boucler sur un cycle de raisonnement et de se coordonner avec d’autres agents pour accomplir des tâches complexes. Cet article explique les patterns d’architecture derrière les repos les plus populaires, survole les ensembles d’outils à connaître, et surtout : vous allez écrire vous-même un Agent Tool-Calling en Java/Spring Boot pour comprendre le mécanisme interne, au lieu de simplement « pip install » et utiliser sans savoir comment ça marche.

2. Pourquoi « agent » est le mot-clé le plus tendance des repos AI en 2026

Auparavant, l’application d’IA la plus courante était RAG (Retrieval-Augmented Generation) : recevoir une question, trouver les documents pertinents, les mettre dans le prompt, appeler le LLM une fois, répondre. Ce modèle est simple mais a une limite claire : le LLM ne fait que « parler », pas « agir ». Il ne peut pas appeler une API pour créer un rendez-vous, il ne peut pas exécuter automatiquement un script pour vérifier le solde d’un compte, il ne peut pas décider par lui-même s’il a besoin d’informations supplémentaires.

Agent résout exactement ce problème : au lieu d’un seul appel au LLM, le système exécute une boucle — le LLM observe l’état actuel, décide d’une action (appeler un tool, demander plus d’infos, ou répondre), exécute l’action, observe le résultat, puis recommence. Voilà pourquoi les dépôts comme les frameworks d’orchestration multi-agent, les SDK agents officiels des fournisseurs de modèles, ou les bibliothèques de workflow pour RAG convergent tous vers une architecture commune : boucle observation – décision – action.

3. Les patterns d’architecture derrière chaque framework d’agent

Même si les noms diffèrent, presque tous les repos d’agents en 2026 reposent sur 4 patterns. Comprendre ces 4 patterns, et la lecture du code source de n’importe quel framework devient familière.

3.1. Boucle ReAct (Reason + Act)

L’idée : le LLM ne répond pas immédiatement, il génère une succession de « réflexion → action → observation » qui se répète plusieurs fois jusqu’à avoir assez d’informations pour répondre enfin.

Thought: Je dois connaître le statut de la commande ORD-001 avant de répondre.
Action: get_order_status(orderId="ORD-001")
Observation: EN_COURS_DE_LIVRAISON
Thought: J'ai les infos, je peux répondre.
Final Answer: Votre commande est en cours de livraison.

3.2. Tool calling / Function calling

Le LLM ne peut pas exécuter le code lui-même — il génère seulement une intention d’appeler une fonction (nom de la fonction + paramètres au format JSON). C’est la partie runtime (le framework d’agent) qui exécute vraiment la fonction et ramène le résultat au LLM. C’est une frontière de sécurité importante : le LLM « propose », votre code « décide s’il faut l’exécuter ».

3.3. Orchestration multi-agent

Un seul agent accumule facilement les responsabilités (il faut la fois planifier, écrire du code, vérifier). Beaucoup de repos divisent le travail entre plusieurs agents spécialisés (planificateur, exécuteur, vérificateur), puis utilisent un « orchestrateur » pour diriger le flux de données entre eux — comme un modèle de microservices, mais entre des « travailleurs » d’IA.

3.4. Memory & state

L’agent doit se souvenir de l’historique de conversation, des résultats des tools appelés, et de l’état d’avancement (quelles étapes sont faites, lesquelles restent). Cette partie est généralement modélisée comme un graphe d’état (machine à états) plutôt qu’une simple suite de messages linéaires, pour que l’agent puisse revenir en arrière, bifurquer, ou attendre une confirmation humaine (human-in-the-loop).

4. Examen des groupes de repos AI agent à étudier en 2026

Au lieu de lister les noms des repos de façon sèche, cette partie les groupe par rôle d’architecture, car c’est ce que vous devez comprendre pour choisir le bon outil pour la bonne tâche.

4.1. Groupe des frameworks d’orchestration

Ces frameworks fournissent le « squelette » pour que vous définissiez un graphe d’étapes (nœuds) et d’arêtes (conditions) entre eux — par exemple, après qu’un agent A répond, s’il faut plus d’infos on bascule vers l’agent B, s’il y en a assez alors on finit. Ils sont forts pour contrôler les flux complexes, supportent des checkpoints pour reprendre après une erreur, et le debugging par visualisation du graphe.

Note : ce groupe a une courbe d’apprentissage plus raide que simplement appeler l’API d’un LLM. Si votre cas d’usage est juste « poser 1 question, avoir 1 réponse », ne traînez pas un moteur graphique entier — le coût opérationnel et de debugging ne vaut pas le coup.

4.2. Groupe des SDK agents officiels

Les grands fournisseurs de modèles (OpenAI, Anthropic) publient leurs propres SDK d’agent, intégrés avec le mécanisme de tool calling, gestion de session, et limite du nombre d’itérations pour éviter qu’un agent ne boucle à l’infini (runaway loop). L’avantage est une compatibilité optimale avec leur modèle, peu de boilerplate. Le désavantage est qu’il est difficile de basculer vers un autre modèle si vous êtes verrouillé sur ce SDK.

4.3. Groupe des workflows RAG + Agent

Ce sont des bibliothèques qui viennent de RAG traditionnel, élargies avec la capacité agent : pas juste retrieve-puis-générer une fois, mais permettre à l’agent de décider lui-même s’il a besoin de chercher à nouveau, d’où. Parfait pour les systèmes de questions-réponses sur des documents internes (knowledge base) de complexité élevée.

Le point commun des trois groupes : tous exposent les 4 patterns de la section 3. Donc pour comprendre profondément, la meilleure façon est de écrire vous-même une boucle d’agent minimale — la prochaine section fait exactement cela.

5. Pratique : construire un Tool-Calling Agent en Java/Spring Boot

Objectif : créer un agent petit qui répond aux questions sur le statut d’une commande. L’agent reconnaîtra automatiquement le numéro de commande dans la question, appellera le « tool » de recherche, puis composera la réponse — exactement la boucle ReAct de la section 3.1.

5.1. Dépendances

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
</dependency>

Note : dans cet exemple, je n’appelle pas un vrai LLM pour que vous puissiez lancer sans clé API. À la section 5.2, l’interface LlmClient est l’endroit où vous pluggez Spring AI (spring-ai-openai-spring-boot-starter) ou le SDK d’Anthropic pour une vraie production.

5.2. Déclarer un Tool

Un Tool est l’unité d’action la plus petite qu’un agent peut appeler. Il a besoin d’un nom (pour que le LLM le choisisse), une description (pour que le LLM comprenne son utilité), et une fonction d’exécution.

public interface AgentTool {
    String name();
    String description();
    String execute(Map<String, String> args);
}

public class OrderStatusTool implements AgentTool {

    private final Map<String, String> orderStatuses = Map.of(
            "ORD-001", "EN_COURS_DE_LIVRAISON",
            "ORD-002", "LIVREE"
    );

    @Override
    public String name() {
        return "get_order_status";
    }

    @Override
    public String description() {
        return "Cherche le statut d'une commande par son identifiant, par exemple ORD-001";
    }

    @Override
    public String execute(Map<String, String> args) {
        String orderId = args.get("orderId");
        return orderStatuses.getOrDefault(orderId, "NON_TROUVEE");
    }
}

execute reçoit les paramètres sous forme de clé-valeur (reproduisant le JSON généré par le LLM) et retourne une observation sous forme de texte — exactement comme Action/Observation dans l’exemple ReAct plus haut.

5.3. Le « cerveau » qui décide de l’étape suivante

En production, cette partie est un appel à un vrai LLM (OpenAI, Claude…) avec un system prompt décrivant la liste des tools. Ici, j’écris un client fondé sur des règles simples pour illustrer la logique décisionnelle sans avoir besoin d’un appel réseau.

public record LlmDecision(DecisionType type, String toolName,
                           Map<String, String> args, String finalAnswer) {
    public enum DecisionType { TOOL_CALL, FINAL_ANSWER }
}

public interface LlmClient {
    LlmDecision decideNextStep(String userQuestion, List<String> observations);
}

public class SimpleOrderLlmClient implements LlmClient {

    private static final Pattern ORDER_PATTERN = Pattern.compile("ORD-\\d+");

    @Override
    public LlmDecision decideNextStep(String question, List<String> observations) {
        if (observations.isEmpty()) {
            Matcher matcher = ORDER_PATTERN.matcher(question);
            if (!matcher.find()) {
                return new LlmDecision(LlmDecision.DecisionType.FINAL_ANSWER, null, null,
                        "Veuillez me donner votre numéro de commande, au format ORD-xxx.");
            }
            Map<String, String> args = Map.of("orderId", matcher.group());
            return new LlmDecision(LlmDecision.DecisionType.TOOL_CALL,
                    "get_order_status", args, null);
        }

        String lastObservation = observations.get(observations.size() - 1);
        String status = lastObservation.split("->")[1].trim();
        return new LlmDecision(LlmDecision.DecisionType.FINAL_ANSWER, null, null,
                "Le statut de votre commande est : " + status);
    }
}

À la première itération (pas encore d’observation), si le client voit un numéro de commande dans la question, il décide TOOL_CALL. À la deuxième itération (il y a une observation du tool), il synthétise tout dans une FINAL_ANSWER. C’est exactement comme un vrai LLM quand on lui donne des tools.

5.4. La boucle d’agent

C’est le cœur de chaque framework d’agent : boucler sur observation – décision – action, avec une limite d’étapes pour éviter une boucle infinie (runaway agent).

public class ReactAgent {

    private static final int MAX_STEPS = 5;

    private final LlmClient llmClient;
    private final Map<String, AgentTool> tools;

    public ReactAgent(LlmClient llmClient, List<AgentTool> toolList) {
        this.llmClient = llmClient;
        this.tools = toolList.stream()
                .collect(Collectors.toMap(AgentTool::name, t -> t));
    }

    public String run(String question) {
        List<String> observations = new ArrayList<>();

        for (int step = 0; step < MAX_STEPS; step++) {
            LlmDecision decision = llmClient.decideNextStep(question, observations);

            if (decision.type() == LlmDecision.DecisionType.FINAL_ANSWER) {
                return decision.finalAnswer();
            }

            AgentTool tool = tools.get(decision.toolName());
            if (tool == null) {
                throw new IllegalStateException(
                        "L'agent a appelé un tool inexistant : " + decision.toolName());
            }

            String result = tool.execute(decision.args());
            observations.add(tool.name() + " -> " + result);
        }

        throw new IllegalStateException("L'agent a dépassé le nombre d'étapes autorisé (" + MAX_STEPS + ")");
    }
}

La limite MAX_STEPS est plus importante que vous ne le pensez : si le LLM ne cesse de décider d’appeler des tools sans jamais retourner FINAL_ANSWER (à cause d’un mauvais prompt, ou parce que le modèle « oublie »), l’agent tourne indéfiniment, gaspille les tokens API et surcharge le système. Chaque SDK d’agent sérieux a ce mécanisme.

5.5. Intégrer dans Spring Boot

@Configuration
public class AgentConfig {

    @Bean
    public ReactAgent reactAgent() {
        return new ReactAgent(new SimpleOrderLlmClient(), List.of(new OrderStatusTool()));
    }
}

@RestController
@RequestMapping("/api/agent")
public class AgentController {

    private final ReactAgent reactAgent;

    public AgentController(ReactAgent reactAgent) {
        this.reactAgent = reactAgent;
    }

    @PostMapping("/ask")
    public String ask(@RequestBody String question) {
        return reactAgent.run(question);
    }
}

Testez :

curl -X POST http://localhost:8080/api/agent/ask \
  -H "Content-Type: text/plain" \
  -d "Pouvez-vous vérifier ma commande ORD-001?"

Le statut de votre commande est : EN_COURS_DE_LIVRAISON

6. Écrire des tests pour le comportement de l’agent

Les agents ont une nature « non-déterministe » (non-deterministic avec un vrai LLM), donc le test le plus important est de vérifier le comportement de bout en bout de la boucle, pas chaque étape interne.

class ReactAgentTest {

    @Test
    void shouldReturnOrderStatus_whenOrderIdPresentInQuestion() {
        ReactAgent agent = new ReactAgent(
                new SimpleOrderLlmClient(), List.of(new OrderStatusTool()));

        String answer = agent.run("Pouvez-vous vérifier ma commande ORD-001?");

        assertThat(answer).contains("EN_COURS_DE_LIVRAISON");
    }

    @Test
    void shouldAskForOrderId_whenQuestionMissingOrderId() {
        ReactAgent agent = new ReactAgent(
                new SimpleOrderLlmClient(), List.of(new OrderStatusTool()));

        String answer = agent.run("Où est ma commande?");

        assertThat(answer).contains("numéro de commande");
    }

    @Test
    void shouldThrow_whenToolNameUnknown() {
        LlmClient brokenClient = (question, observations) ->
                new LlmDecision(LlmDecision.DecisionType.TOOL_CALL, "no_such_tool", Map.of(), null);
        ReactAgent agent = new ReactAgent(brokenClient, List.of(new OrderStatusTool()));

        assertThatThrownBy(() -> agent.run("n'importe quoi"))
                .isInstanceOf(IllegalStateException.class)
                .hasMessageContaining("inexistant");
    }
}

Le troisième test reproduit une situation très réelle : le LLM « hallucine » (génère un nom de tool qui n’existe pas dans le registre). L’agent runtime doit l’empêcher avec une exception claire, au lieu de l’ignorer silencieusement ou de crasher de façon incompréhensible.

7. Erreurs courantes et quand NE PAS utiliser un framework d’agent

Erreurs courantes :

• Ne pas limiter le nombre d’étapes → l’agent tourne à l’infini si le LLM ne décide jamais de s’arrêter. Toujours définir MAX_STEPS ou un timeout total.
• Faire confiance à 100 % aux paramètres générés par le LLM → le LLM peut générer un orderId au mauvais format ou avec une valeur inexistante. Le tool doit valider lui-même, sans supposer que l’entrée de l’agent est sûre, comme vous ne feriez pas confiance aux données d’un client.
• Donner à l’agent des tools avec accès à des données sensibles en écriture/suppression sans validation humaine (human-in-the-loop) → une mauvaise décision du LLM pourrait supprimer accidentellement des données en production.
• Mettre trop de tools dans un seul agent → le LLM confond facilement quand la liste est longue et les descriptions (description) pas assez claires pour différencier.

Quand NE PAS utiliser un framework d’agent :

• Le problème ne demande qu’un seul appel au LLM, pas besoin de tools, pas de boucle — appelez directement l’API chat completion, ne traînez pas un graphe d’orchestration pour compliquer les choses.
• Le système exige des résultats déterministes (deterministic) absolus, par exemple calcul d’impôt, calcul de salaire — un agent basé sur un LLM ne garantit pas 100 % de cohérence, utilisez de la logique métier pure.
• Le coût opérationnel (chaque étape de la boucle = un appel LLM, des tokens dépensés) n’a pas été bien étudié — un agent multi-étapes peut coûter plus cher que vous le pensez à l’échelle.

8. Conclusion

Les repos d’agent IA remarquables en 2026 ne sont pas de la « magie » — ils reposent tous sur 4 patterns familiers : la boucle ReAct, le tool calling, l’orchestration multi-agent, et la mémoire/état. Quand vous écrivez vous-même un ReactAgent minimaliste comme à la section 5, lire le code source de n’importe quel grand framework devient beaucoup plus facile à anticiper, car au fond ils ne font que compliquer cette boucle. Avant de choisir un repo pour la production, posez-vous la question : ai-je vraiment besoin d’une boucle observation — décision — action, ou un simple appel LLM suffirait ?