Contexte technique
Ce n'est pas tant la question de l'entretien qui a attiré mon attention, mais sa formulation. Si l'on demande à un candidat de décomposer OpenClaw en conception de système, cela signifie que le marché n'attend plus seulement « quelqu'un qui sait appeler l'API d'un modèle », mais un ingénieur qui comprend l'architecture de l'IA et peut mettre en production l'automatisation par l'IA.
J'ai examiné les descriptions disponibles d'OpenClaw, et le tableau est assez clair. Il ne s'agit pas d'un simple wrapper autour d'un chat, mais d'un framework d'agents avec une séparation entre le modèle, la mémoire, les outils et l'orchestration. Le comportement de l'agent est défini par une approche « workspace-first » : des fichiers distincts pour son rôle, ses capacités, son identité et sa logique d'exécution.
C'est là que ça devient intéressant. Ce format est très pratique à aborder lors d'un entretien de conception de système, car il soulève immédiatement des questions matures : où l'état est-il stocké, comment les permissions des outils sont-elles limitées, que fait la boucle de « heartbeat », comment sont structurés les hooks pour la journalisation, les politiques et les contrôles de sécurité.
J'aime aussi le fait qu'OpenClaw oblige à penser en termes de frontières du système, et non de prompts. Si un agent peut appeler des actions externes, on ne peut plus se contenter de la magie d'une belle démo : il faut des mécanismes de relance, d'audit, d'idempotence, de contrôle des coûts et une observabilité adéquate.
En substance, les recruteurs testent une chose : savez-vous concevoir l'intégration de l'IA comme un système vivant, et non comme un notebook avec un prompt astucieux ? Et honnêtement, c'est une évolution saine.
Impact sur l'entreprise et l'automatisation
Pour les entreprises, le signal est direct. Les équipes qui gagnent sont celles qui construisent déjà des pipelines d'agents avec de la mémoire, des outils et des politiques d'accès. Celles qui perdent sont celles qui vendent encore un « bot IA » sans penser à ce qui se passera à la centième étape, en cas de panne d'API ou d'un appel d'outil dangereux.
Le deuxième effet concerne le recrutement. Il ne suffit plus de dire « j'ai travaillé avec des LLM ». À la place des entreprises, je vérifierais si un ingénieur peut construire une architecture pour un flux de travail réel : files d'attente, étapes d'approbation, logs, modèles de secours, accès sécurisé à un CRM ou à des données internes.
Chez Nahornyi AI Lab, nous résolvons précisément ce genre de problèmes pour nos clients : nous ne nous contentons pas de connecter un modèle, nous construisons un développement de solution IA autour d'une opération spécifique, où la vitesse, le contrôle et un coût d'erreur clair sont cruciaux.
Si votre entreprise a besoin d'automatiser des processus où un chatbot atteint ses limites, examinons l'architecture de manière calme et mature. Chez Nahornyi AI Lab, je commence généralement par une cartographie des risques et des goulots d'étranglement, puis nous décidons où l'automatisation par l'IA est nécessaire et où il vaut mieux ne pas du tout laisser un agent intervenir.