Comment les agents OpenClaw remplacent les employés, pas les tâches
Je construis des agents IA depuis des mois maintenant. Pipelines personnalisés, automatisations Claude Code, systèmes multi-agents : toute la pile. Et la plupart du temps, je les utilisais mal.
Ce n’est pas faux, à l’évidence. Mes agents ont travaillé. Ils ont accompli des tâches. Ils ont produit des résultats. Mais chaque fois que j'avais besoin de faire quelque chose, je devais m'asseoir, rédiger l'invite, surveiller l'exécution, examiner le résultat, puis tout recommencer le lendemain. J'avais automatisé le travail mais pas le flux de travail. L'agent était un outil que j'ai ramassé et déposé. Pas un membre de l’équipe qui s’est présenté et a fait son travail.
Ensuite, j'ai regardé l'analyse de Brian Castle sur la façon dont il gère son entreprise sur les agents OpenClaw, et quelque chose qui m'avait manqué s'est déclenché. La distinction est d'une simplicité trompeuse, mais elle a complètement changé ma façon de penser la délégation de l'IA : il y a une énorme différence entre confier une tâche à un agent et confier un travail à un agent.
Une tâche consiste à « résumer cet article ». Un travail consiste à "chaque matin à 7 heures du matin, scanner ces douze sources industrielles, identifier les trois annonces les plus pertinentes, rédiger un briefing et l'envoyer sur mon Telegram". La première m'oblige à me présenter et à demander. L'autre m'oblige à le configurer une fois, puis à m'écarter.
Ce recadrage – des tâches aux emplois – a débloqué quelque chose avec lequel je luttais depuis des semaines. Et le système que Brian a construit autour de lui mérite d'être compris en détail, que vous utilisiez OpenClaw ou tout autre framework d'agent. Les principes sont transférés.
Voici ce que j'ai appris, ce que j'ai commencé à mettre en œuvre et les points faibles de cette approche dont personne ne parle.
Pourquoi la plupart des gens atteignent un plafond avec les agents IA
Il y a un modèle que je vois constamment – dans mon propre travail et dans chaque communauté de créateurs d’IA dont je fais partie. Quelqu'un découvre des agents IA. Ils sont excités. Ils automatisent certaines choses. Et puis... ils plafonnent.
Le plateau se produit parce que la délégation basée sur les tâches n'évolue pas. Chaque fois que vous déléguez une tâche ponctuelle, vous payez un coût de configuration : définition du contexte, création d'invites, révision des résultats. Pour une seule tâche complexe, ce coût en vaut la peine. Mais lorsque vous déléguez vingt tâches par jour, chacune nécessitant un nouveau contexte, vous vous créez essentiellement un deuxième travail : gérer les agents.
J'ai frappé durement ce mur vers le troisième mois. J'avais des agents capables d'écrire, de rechercher, d'analyser et de coder. Mais je passais deux heures par jour à les orchestrer. Mettre le travail en file d'attente, vérifier les résultats, réexécuter les tentatives infructueuses. Mon « automatisation » s'était transformée en une liste de tâches très sophistiquée qui me demandait toujours à chaque étape.
Brian Castle définit parfaitement ce problème : vous traitez les agents comme des entrepreneurs que vous embauchez pour un travail, plutôt que comme des employés que vous embauchez pour un rôle. Les entrepreneurs ont besoin d’une nouvelle étendue de travail à chaque mission. Les employés apprennent le travail une fois, puis l'exécutent à plusieurs reprises, s'améliorant au fil du temps avec un minimum de surveillance.
Le passage d’une pensée d’entrepreneur à une pensée d’employé change tout dans la façon dont vous concevez vos systèmes d’agents. Et cela commence par une question que la plupart des constructeurs d’IA ne posent jamais : quels sont les emplois récurrents dans mon entreprise ?
Pas des tâches. Des emplois. Un travail prévisible et répété qui se déroule selon une cadence connue (quotidienne, hebdomadaire, mensuelle) et suit un processus cohérent à chaque fois.
Lorsque je me suis assis et que j'ai cartographié cela pour mon propre travail, j'ai trouvé dix-sept tâches récurrentes que j'avais effectuées manuellement. Dix-sept. Analyse de recherche, rédaction de contenu, résumés de révision de code, rapports de mise à jour client, surveillance des bulletins de sécurité, suivi des concurrents. J'ai fait toutes choses à peu près selon le même calendrier, en suivant à peu près le même processus, produisant à peu près le même type de résultat.
Dix-sept emplois qui n'avaient pas besoin de moi. Ils avaient besoin d’un agent qui connaissait le processus et qui se présentait à temps.
Mais savoir que vous avez besoin d’agents récurrents et construire un système qui les exécute de manière fiable sont deux problèmes très différents. C'est là que le cadre technique de Brian devient intéressant – et là où j'ai commencé à voir des lacunes dans ma propre configuration que je n'avais pas reconnues.
L'architecture derrière une équipe d'agents autonome
Le système de Brian fonctionne sur une pile de composants spécialement conçus, et comprendre comment ils s'assemblent révèle des principes qui s'appliquent quels que soient vos outils spécifiques.
La base est OpenClaw lui-même, fonctionnant sur un Mac Mini. Considérez-la comme une agence pour l'emploi : elle héberge et exécute les agents. Mais OpenClaw ne résout pas à lui seul le problème de l’orchestration. Une plateforme d'agents vous donne des travailleurs. Ce dont vous avez besoin, c'est d'un système de gestion.
C'est là qu'intervient BMHQ (Builder Methods HQ). Il s'agit d'une application Rails personnalisée que Brian a construite comme contrôle de mission. Imaginez un tableau Kanban spécialement conçu pour la gestion des agents IA : modèles de tâches, planification, répartition, suivi du statut et examen des résultats, le tout dans un seul tableau de bord.
Voici ce qui se passe en pratique. Une tâche récurrente – par exemple « analyser les actualités de l’industrie de l’IA et produire un briefing quotidien » – existe comme modèle dans BMHQ. Le planificateur le déclenche à l'heure configurée. Le code de répartition personnalisé envoie la tâche directement à l'agent affecté via la passerelle d'OpenClaw. L'agent le récupère, l'exécute, produit le résultat et envoie une notification d'achèvement via Telegram.
Aucun humain dans la boucle pour l'exécution. L'humain examine les résultats lorsque cela lui convient, et non lorsque l'agent a besoin de l'autorisation pour continuer.
Je veux m'attarder sur l'article de Telegram car il est subtilement brillant. La plupart des configurations d'agents que j'ai vues (y compris la mienne, jusqu'à récemment) vous obligent à consulter un tableau de bord ou à ouvrir un terminal pour voir ce que vos agents ont produit. Les agents de Brian envoient des notifications et des liens directs vers lui via Telegram. Les agents viennent vers lui. Il ne va pas vers eux.
Cela inverse le modèle d’attention. Au lieu de gérer activement les agents, vous recevez passivement leurs résultats et ne vous engagez que lorsque quelque chose doit être corrigé. C'est la différence entre gérer une équipe et microgérer une équipe. Et c'est le choix architectural qui rend plus de vingt emplois d'agent récurrents durables pour une seule personne.
La couche de gestion des résultats est tout aussi réfléchie. Les agents produisent des fichiers de démarques stockés dans des dossiers Dropbox partagés, accessibles via un éditeur de démarques personnalisé appelé Brainown. Chaque notification Telegram comprend un lien direct vers le fichier concerné. Un clic : vous lisez le résultat de l'agent. Vous voulez le modifier ? Vous êtes déjà dans l'éditeur.
Ce qui m'a frappé dans cette architecture, ce n'est pas sa complexité, c'est sa spécificité. Chaque composant existe pour résoudre un point de friction apparu lors de l’exécution réelle d’agents à grande échelle. L'application Rails personnalisée, l'intégration Telegram, l'éditeur de démarques – aucun de ces éléments n'est techniquement impressionnant isolément. Mais ensemble, ils éliminent les frais généraux qui poussent la plupart des gens à abandonner les flux de travail des agents une fois que l'enthousiasme initial s'est estompé.
La question sur laquelle je revenais sans cesse : pourrais-je construire quelque chose d’équivalent ? Et plus important encore, devrais-je ? Nous y reviendrons.
Compétences : la partie où tout le monde se trompe
C'est ici que le cadre de Brian s'écarte de la façon dont la plupart des gens – y compris moi, jusqu'à récemment – configurent les agents IA. Et honnêtement, c’est peut-être le concept le plus transférable de tout le système.
Lorsque vous configurez un agent pour effectuer une tâche récurrente, l’instinct naturel est d’intégrer toutes les instructions directement dans l’invite de tâche. "Voici quoi faire, voici comment le formater, voici où le sauvegarder, voici ce qu'il faut éviter." Une grande invite qui contient tout.
Le problème : lorsque vous devez mettre à jour le processus, vous devez rechercher et modifier chaque tâche qui fait référence à ces instructions. Vous avez dix tâches récurrentes qui suivent toutes la même méthodologie de recherche ? Vous disposez désormais de dix emplacements pour effectuer la même modification. Si vous en manquez une, vos agents exécutent des processus incohérents.
La solution de Brian est ce qu'il appelle Skills : une documentation de processus modulaire stockée sous forme de fichiers de démarques séparés avec des scripts et des documents de référence intégrés. Les tâches ne contiennent pas les instructions. Ils font référence à une compétence.
Le dossier de compétences est la seule source de vérité sur la manière dont un type de travail spécifique doit être effectué. Besoin de changer le processus de recherche ? Mettez à jour un fichier de compétences. Chaque tâche qui y fait référence utilise automatiquement le processus mis à jour lors de sa prochaine exécution.
Si vous avez déjà travaillé dans le génie logiciel, c'est le principe DRY (Don't Repeat Yourself) appliqué à la gestion des agents. Et c’est une de ces idées qui paraissent évidentes rétrospectivement mais qui changent tout en pratique.
J'en ai implémenté une version dans ma propre configuration dans les quarante-huit heures qui ont suivi la panne de Brian. Mon agent de recherche de contenu IA avait auparavant une invite de 2 000 jetons intégrée dans chaque configuration de tâche. Il fait désormais référence à un fichier « content-research-skill.md » qui se trouve dans un répertoire partagé. Lorsque j'ai réalisé que l'agent manquait systématiquement des données sur les prix des concurrents dans ses résultats de recherche, j'ai mis à jour un fichier. Le lendemain matin, les trois tâches de recherche faisant référence à cette compétence ont produit des résultats comprenant une analyse des prix.
Une modification. Trois sorties améliorées. Auparavant, cela aurait été trois révisions d'invite distinctes, trois tests distincts et probablement un que j'ai oublié de mettre à jour jusqu'à ce que je remarque l'incohérence une semaine plus tard.
Les compétences créent également une boucle d’amélioration naturelle. Lorsque vous examinez le résultat d’un agent et trouvez une lacune, vous mettez à jour la compétence. La mise à jour se propage à chaque exécution future. Au fil du temps, le document de compétences s'affine de plus en plus : un manuel d'exploitation évolutif qui capture vos connaissances accumulées sur la façon dont un type de travail spécifique doit être effectué.
Il existe ici un principe plus profond qui s’applique au-delà des agents IA. Tout processus reproductible qui n’est pas documenté dans un emplacement unique et modifiable dérivera. Les agents ne s'ennuient pas et ne prennent pas de raccourcis comme le font les humains, mais ils suivront des instructions obsolètes avec une parfaite cohérence si vous ne maintenez pas la source de la vérité.
L’approche basée sur les compétences facilite également considérablement l’intégration de nouveaux agents ou le remplacement du modèle sous-jacent. Votre connaissance des processus réside dans les fichiers de compétences, et non dans la configuration d'un agent spécifique. Passer d'un modèle à un autre ? Dirigez le nouvel agent vers les mêmes compétences. Vos connaissances institutionnelles sont transférées instantanément.
Ce concept à lui seul – séparer la documentation des processus de l'exécution des tâches – valait plus pour moi que n'importe quel outil spécifique de la pile de Brian. Et cela s'applique que vous utilisiez OpenClaw, les agents Claude Code, LangChain, CrewAI ou toute autre chose.
Si vous avez suivi et hoché la tête, vous êtes prêt pour la partie où j'explique ce qui s'est passé lorsque j'ai réellement essayé de mettre en œuvre tout cela. Spoiler : ce n’était pas aussi fluide que je le laisse entendre.
Ce que j'ai construit (et ce qui s'est cassé)
J'ai passé un week-end à construire ma propre version du système de Brian. Pas un clone - je n'ai pas (encore) besoin d'une application Rails personnalisée - mais un équivalent fonctionnel utilisant les outils que j'avais déjà.
Ma pile : Agents Claude Code pour l'exécution. Un simple planificateur Python utilisant APScheduler pour la répartition des tâches récurrentes. Fichiers de compétences Markdown dans un répertoire partagé. Bot Telegram pour les notifications. Coffre-fort en obsidienne pour le stockage et l'examen des sorties.
Premier jour : j'ai mis en place cinq tâches récurrentes. Analyse matinale de l'industrie. Résumé quotidien des validations de code dans mes dépôts actifs. Analyse concurrentielle bihebdomadaire pour un projet client. Rapport hebdomadaire sur l'état du pipeline de contenu. Compilation mensuelle de bulletins de sécurité pour le contenu xcybersecurity.io.
Deuxième jour : trois des cinq tâches se sont exécutées avec succès lors de leur première exécution automatisée. L’analyse de l’industrie a produit un briefing clair. Le résumé de la validation du code était précis et bien formaté. Le modèle de rapport hebdomadaire a parfaitement fonctionné.
L'analyse concurrentielle a échoué car le fichier de compétences faisait référence à une source de données nécessitant une authentification que je n'avais pas configurée dans l'environnement de l'agent. Ma faute : la documentation du processus était incomplète car j'avais effectué cette étape manuellement sans me rendre compte du tout qu'il s'agissait d'une étape.
Le travail du bulletin de sécurité a produit un résultat, mais c'était un déchet. Le dossier de compétences était trop vague sur ce qui constitue un événement de sécurité « notable », et l'agent a interprété cette ambiguïté en incluant tout : dix-sept pages de chaque CVE publié ce mois-là. J'avais besoin de définir des critères de filtrage explicites : seuils de gravité, catégories technologiques concernées, pertinence par rapport à notre clientèle.
Les deux échecs m’ont appris la même leçon : les compétences doivent être plus explicites qu’on ne le pense. Lorsque vous effectuez un travail vous-même, vous détenez des connaissances implicites sur des dizaines de micro-décisions que vous prenez inconsciemment. L'agent n'a aucune connaissance implicite. Chaque critère de décision doit être explicite dans le fichier de compétences, sinon l'agent devinera (mal) ou inclura tout (inutilement).
Au cinquième jour, les cinq tâches fonctionnaient de manière fiable. J'en ai ajouté deux autres. Au dixième jour, j'avais neuf tâches d'agent récurrentes exécutées avec une surveillance minimale. Ma routine matinale est passée de « m'asseoir et commencer à déléguer » à « ouvrir Telegram, examiner ce que mes agents ont produit pendant la nuit, signaler tout ce qui nécessite une révision ».
Le gain de temps a été réel mais pas là où je l’attendais. Le temps d’exécution réel économisé était peut-être de quatre-vingt-dix minutes par jour – ce qui est significatif mais ne change pas la vie. Le véritable gain était cognitif. J'ai arrêté de porter dix-sept tâches récurrentes dans ma file d'attente mentale. Mon cerveau ne suivait pas ce qui devait se passer aujourd'hui parce que le système le suivait. Cela a libéré de la bande passante mentale pour le travail qui m'exige réellement : décisions d'architecture, conversations avec les clients, résolution créative de problèmes.
Voici le chiffre qui m'a le plus surpris : après deux semaines, j'avais examiné environ soixante-dix résultats d'agents. Parmi ceux-ci, cinquante-huit n’ont nécessité aucune modification. Neuf d'entre eux nécessitaient des corrections mineures. Trois d’entre eux nécessitaient une refonte importante. Cela représente un taux de réussite entièrement autonome de 83 % et un taux de résultats de 96 % utilisables avec au plus des ajustements mineurs.
Pas parfait. Mais envisagez l’alternative : effectuer moi-même les soixante-dix de ces tâches. Les agents ne remplacent pas mon jugement. Ils remplacent l'exécution dans laquelle mon jugement n'a pas besoin d'être impliqué.
L'économie dont personne ne parle
Brian fait valoir un point qui mérite plus d’attention : les aspects économiques de l’embauche d’agents IA sont fondamentalement différents de ceux de l’embauche d’humains.
Avec un employé humain, il existe une charge de travail minimale viable qui justifie le coût. Vous n'embauchez pas un chercheur à temps plein pour faire deux heures de recherche par semaine. Le salaire, les avantages sociaux, les frais généraux de gestion : rien de tout cela n’a de sens en dessous d’un certain seuil de travail récurrent.
Les agents IA n’ont pas de charge de travail minimale viable. Un agent qui exécute une tâche par jour vous coûte quelques centimes en jetons API. Un agent qui exécute vingt tâches par jour vous coûte quelques dollars. Il n'y a pas de salaire, pas d'avantages sociaux, pas de temps d'intégration au-delà de la configuration initiale des compétences.
Cela change le calcul pour lequel les tâches méritent d'être déléguées. Des tâches qui ne justifieraient jamais l’embauche d’un humain – parce que le volume est trop faible ou la fréquence trop sporadique – justifient absolument le déploiement d’un agent.
J'ai fait le calcul de mes neuf emplois d'agent récurrents. Coût mensuel total du jeton pour tous les agents : environ 34 $. Temps total que ces tâches me prendraient pour effectuer manuellement : environ 45 heures par mois. Même en valorisant mon temps à un modeste 50 $/heure, cela représente une valeur de 2 250 $ sur 34 $ en coûts d'infrastructure.
Le ratio devient encore plus convaincant à mesure que vous évoluez. Brian gère des dizaines de postes d'agent récurrents. Ses coûts d'infrastructure sont plus élevés – il utilise un Mac Mini dédié, paie pour OpenClaw, gère des applications personnalisées – mais le coût par tâche reste négligeable par rapport à ce que ce travail coûterait en main d'œuvre humaine.
Il y a cependant un piège. Le coût d'installation est réel. Brian a créé des applications Rails personnalisées. J'ai passé un week-end à coder un planificateur et à configurer des intégrations. La rédaction de bons fichiers de compétences prend des heures d'itération par tâche. L'investissement initial se mesure en temps d'ingénierie, et non en dollars, et pour les utilisateurs non techniques, cet investissement peut être prohibitif.
Il s’agit là d’un compromis honnête : les systèmes d’agents d’IA récurrents permettent de gagner énormément de temps à grande échelle, mais ils nécessitent de réels efforts d’ingénierie pour être configurés correctement. Les personnes qui en bénéficient le plus sont les constructeurs qui peuvent écrire leurs propres outils – ce qui correspond exactement au public de Brian et, franchement, au mien aussi.
Si vous ne pouvez pas créer votre propre système de planification et de répartition, vous dépendez des outils d'orchestration disponibles dans le commerce. À l’heure actuelle, début 2026, ces outils s’améliorent rapidement mais présentent encore des lacunes importantes par rapport aux solutions sur mesure. Cet écart va se combler. Mais aujourd’hui, les plus gros bénéfices vont à ceux qui sont capables de construire leur propre infrastructure.
Ce que je ferais différemment en partant de zéro
Deux semaines après avoir utilisé ce système, voici ce que j'aurais aimé savoir dès le premier jour.
Commencez avec trois emplois, pas neuf. J'étais excité et sur-déployé. Trois tâches bien configurées avec des fichiers de compétences raffinés vous en apprennent plus de neuf configurées à la hâte. Obtenez la bonne boucle de rétroaction (exécution, révision, perfectionnement des compétences) avant de passer à l'échelle.
Écrivez des fichiers de compétences comme si vous formiez quelqu'un qui n'a jamais fait le travail. Chaque hypothèse que vous laissez implicite apparaîtra comme un mode d'échec. Documentez les critères de décision, les cas extrêmes, les choses « évidentes » que vous faites sans réfléchir. L'agent a besoin de tout cela.
Construisez d'abord la couche de notification. Avant la planification, avant l'expédition, avant toute autre chose, configurez la manière dont vos agents communiqueront avec vous. Si vous ne pouvez pas facilement voir ce qu'ils ont produit, vous n'examinerez pas les résultats de manière cohérente, et des résultats non examinés signifient des processus non améliorés.
Ne créez pas d'outils personnalisés tant que vous n'avez pas validé le flux de travail manuellement. J'aurais pu gagner six heures en exécutant mes cinq premières tâches avec répartition manuelle (en envoyant simplement la tâche à l'agent moi-même dans les délais) avant de créer le planificateur automatisé. L'exécution manuelle aurait comblé le manque d'authentification et le vague fichier de compétences avant que j'investisse dans l'automatisation des processus défectueux.
** Prévoyez deux heures de perfectionnement des compétences par tâche au cours de la première semaine. ** Il ne s'agit pas d'un système à définir et à oublier. Les cinq à dix premières exécutions d’une tâche récurrente révéleront des lacunes dans la documentation de vos compétences. Planifiez cette itération. Les fichiers de compétences qui fonctionnaient sans problème le quatorzième jour ont commencé comme des ébauches médiocres le premier jour.
Brian préconise la création de vos propres outils à l'aide de Claude Code, et je suis d'accord, mais avec la mise en garde que vous devez valider le flux de travail avant d'optimiser l'outillage. Construisez la bonne chose, puis construisez-la bien. Pas l'inverse.
Vue d'ensemble : les agents IA en tant qu'infrastructure et non fonctionnalités
Voici ce qui me préoccupe depuis que j’ai commencé à utiliser ce système.
La plupart des conversations sur les agents IA se concentrent sur ce qu’ils peuvent faire. Peuvent-ils écrire du code ? Peuvent-ils analyser les données ? Peuvent-ils générer du contenu ? Ce sont des questions de capacités. Elles comptent, mais ce ne sont plus les questions les plus importantes.
La question la plus importante est la suivante : peuvent-ils se présenter de manière fiable, tous les jours, et effectuer un travail que vous auriez autrement dû faire vous-même ou embaucher quelqu'un pour le faire ?
C'est une question d'infrastructure. Et cela nécessite une réflexion sur l’infrastructure : planification, surveillance, documentation des processus, gestion des résultats, amélioration continue. Les mêmes systèmes ennuyeux mais essentiels qui font fonctionner toute équipe.
Le cadre de Brian m'a bien plu car il traite les agents d'IA comme une infrastructure organisationnelle plutôt que comme des outils de productivité individuels. Les agents ne le rendent pas plus productif à son bureau. Ils gèrent le travail qui se produit, qu'il soit à son bureau ou non. Sa matinée ne commence pas par « que dois-je déléguer aujourd'hui ? Cela commence par « qu'est-ce que mon équipe a produit du jour au lendemain ? »
Ce changement de mentalité – de la délégation active à l’examen passif – est le véritable déverrouillage. Et cela ne nécessite pas spécifiquement OpenClaw, ni une application Rails personnalisée, ni aucun outil particulier. Cela nécessite de penser aux agents IA de la même manière que vous penseriez à la constitution d'une équipe : définir les rôles, documenter les processus, mettre en place des canaux de communication, revoir le travail et s'améliorer continuellement.
Je suis encore au début de ce voyage. Neuf emplois récurrents, 34 $ par mois, un taux de réussite autonome d'environ 83 %. Ces chiffres s'amélioreront à mesure que mes fichiers de compétences mûriront. J'ajouterai plus d'emplois à mesure que j'identifierai des travaux plus récurrents qui ne nécessitent pas mon implication directe.
Mais la question fondamentale a déjà trouvé sa réponse pour moi. Les agents IA ne sont pas seulement des outils que j'utilise lorsque j'ai besoin d'aide. Ce sont des membres d’équipe qui effectuent un vrai travail selon un horaire réel. La seule chose qui manquait était le système permettant de rendre cela possible.
Si vous construisez avec des agents IA et que vous avez atteint le plateau (celui où vous passez plus de temps à gérer les agents que les agents ne vous en font gagner), arrêtez d'ajouter des fonctionnalités. Commencez à ajouter une infrastructure. Définir les emplois. Écrivez les compétences. Construisez le calendrier. Laissez les agents faire ce pour quoi ils sont vraiment bons : se présenter à chaque fois et suivre le processus sans s'ennuyer, se distraire ou s'épuiser.
Ce n'est pas une possibilité future. C'est un projet du mardi après-midi. La question est de savoir si vous allez le construire cette semaine ou si vous continuerez à tout faire manuellement jusqu'à ce que vous soyez enfin suffisamment frustré pour essayer.
Je sais déjà ce que je recommanderais.
🤝 Travaillons ensemble
Vous cherchez à créer des systèmes d’IA, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.
- 🔗 Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
- 🌐 Portfolio : mejba.me
- 🏢 Ramlit Limited (solutions d'entreprise) : ramlit.com
- 🎨 ColorPark (conception et image de marque) : colorpark.io
- 🛡 xCyberSecurity (services de sécurité) : xcybersecurity.io
