Les plugins Cloud Co-work viennent de briser le modèle SaaS

Les plugins Cloud Co-work viennent de briser le modèle SaaS

J'ai vu 47 milliards de dollars de capitalisation boursière SaaS s'évaporer en une seule séance de trading le mois dernier. Pas à cause d'un manque à gagner sur les résultats. Pas à cause d'une peur de récession. Parce qu'Entropic a livré une fonctionnalité appelée plugins pour Cloud Co-work — et Wall Street a immédiatement compris ce que ça signifiait pour chaque outil par abonnement qui traîne dans tes onglets de navigateur en ce moment.

Ce chiffre a résonné différemment quand je fixais les quinze applications SaaS ouvertes sur ma propre machine. Slack. Notion. Asana. Linear. Trois tableaux de bord analytiques différents. Un CRM que j'utilise à peine mais pour lequel je paie 49 $/mois. Un outil de handoff design. Deux plateformes email différentes. Je les ai comptées, j'ai eu un peu la nausée, et ensuite j'ai passé les soixante-douze heures suivantes à reconstruire l'intégralité de mon workflow autour des plugins Cloud Co-work.

Ce qui s'est passé ensuite a changé ma façon de penser le logiciel. Pas de manière incrémentale. Fondamentalement.

Voici ce que la plupart des gens ne voient pas dans ce moment — ce n'est pas que les plugins rendent Cloud Co-work plus intelligent. Ça, c'est l'analyse de surface. Le vrai changement est architectural. Les plugins transforment un seul agent IA en une interface universelle qui absorbe les fonctionnalités de dizaines d'outils autonomes. Et une fois que tu comprends les mécaniques de comment ça fonctionne, tu commences à voir pourquoi les PDG du SaaS paniquent discrètement derrière leurs communiqués de presse « nous accueillons l'intégration de l'IA ».

Je vais te guider pas à pas à travers ce que sont exactement ces plugins, comment je les utilise pour remplacer des outils que je paie depuis 2021, et pourquoi je pense qu'on assiste aux premières manches du plus grand changement de plateforme depuis que le mobile a dévoré le logiciel desktop. Mais d'abord, tu dois comprendre l'anatomie d'un plugin — parce que ce qu'Entropic a construit est plus élégant que la plupart des gens ne le réalisent.

Ce qu'est vraiment un plugin (et pourquoi l'analogie de l'« App Store » ne tient pas)

Tout le monde compare les plugins Cloud Co-work à un app store. Je comprends l'impulsion, mais la comparaison rate complètement le sujet.

Un app store te donne des applications autonomes qui font chacune leur truc isolément. Les plugins sont différents. Vois-les plutôt comme une clé USB que tu branches dans le cerveau d'un collègue déjà brillant. Tu ne lui donnes pas une nouvelle app — tu lui donnes une nouvelle expertise, un nouvel accès, et de nouveaux workflows qui s'intègrent avec tout ce qu'il sait déjà.

Chaque plugin regroupe trois composants, et comprendre les trois est essentiel.

Les Skills sont le cerveau de l'opération. Un skill est défini dans un fichier markdown — oui, un simple fichier texte markdown — qui contient des instructions, des connaissances métier, des documents de référence, et parfois même des configurations de sous-agents. Quand j'ai construit mon premier skill personnalisé, j'ai littéralement écrit un document expliquant comment j'écris mes posts LinkedIn, inclus cinq exemples de mes meilleurs posts en termes de performance, et décrit mon ton de voix. Cloud Co-work l'a absorbé et a commencé à produire des brouillons qui sonnaient comme moi. Pas « une IA qui essaie de sonner comme moi. » Vraiment moi. Ma femme en a lu un et m'a demandé quand j'avais trouvé le temps de l'écrire.

Les Connections gèrent la tuyauterie. Ce sont des intégrations sécurisées qui permettent à Cloud Co-work de communiquer avec tes outils existants — ton CRM, ton système de gestion de projet, ton email, ton stockage de fichiers. Le détail clé qui compte : les connections sont cloisonnées par département. Le plugin de ton équipe marketing peut accéder au calendrier éditorial et aux comptes sociaux sans jamais toucher aux données de facturation de l'équipe finance. Ce n'est pas un ajout après coup. C'est de l'architecture centrale, et ça résout le problème de sécurité qui tue la plupart des conversations « IA en entreprise » avant même qu'elles commencent.

Les Commands sont les déclencheurs. Des slash commands qui lancent des skills spécifiques ou enchaînent plusieurs skills ensemble dans ce qu'Entropic appelle des workflows agentiques. Une commande. Plusieurs skills qui s'exécutent en séquence. Les sorties de l'un alimentant l'entrée du suivant.

Quand tu regroupes skills, connections et commands ensemble, tu obtiens un plugin. Et quand tu commences à chaîner des plugins ensemble — c'est là que ça devient vraiment dingue. Je te montrerai exactement comment j'ai mis ça en place dans la section implémentation, mais en version courte : j'ai remplacé un workflow de repurposing de contenu à six outils par une seule slash command qui prend environ neuf secondes à déclencher.

Ce n'est pas une optimisation. C'est un changement de catégorie.

Pourquoi j'ai arrêté de balayer ça comme « juste une autre fonctionnalité IA »

Je vais être honnête — ma première réaction a été le scepticisme. Je construis avec des agents IA depuis plus d'un an maintenant. J'ai vu des dizaines de lancements « ça change tout » qui n'ont changé approximativement rien. Quand Entropic a annoncé les plugins, j'ai supposé que c'était du théâtre marketing. Habiller quelques templates de prompts, les appeler plugins, obtenir un cycle médiatique.

J'avais tort. Et comprendre pourquoi j'avais tort est important, parce que le même scepticisme empêche beaucoup d'ingénieurs compétents de reconnaître ce qui se passe ici.

La différence entre les plugins Cloud Co-work et chaque outil d'« automatisation IA » que j'ai testé, c'est la composabilité. La plupart des outils IA te donnent un pipeline figé : l'input entre, l'output sort, et si l'output n'est pas tout à fait bon, tu recommences avec un prompt différent. Les plugins créent un système vivant où les skills se construisent les uns sur les autres, partagent du contexte, et s'adaptent à ta logique métier spécifique.

Voici un exemple concret qui m'a convaincu. J'avais besoin de créer une étude de cas pour un projet client. Normalement, mon workflow ressemble à ça : transcrire l'interview client dans Otter, la nettoyer dans Google Docs, extraire les métriques du projet depuis notre tableau de bord, rédiger l'étude de cas dans Notion en utilisant notre template de marque, créer des citations pour les réseaux sociaux, générer un post LinkedIn, et planifier le tout dans Buffer. Six outils. Environ quatre-vingt-dix minutes si tout se passe bien. Les choses se passent rarement bien.

Avec un seul plugin Cloud Co-work, j'ai alimenté la transcription brute et le document de guidelines de marque. Une commande. L'agent a traité la transcription, extrait les métriques clés et les citations, généré une étude de cas complète correspondant à la structure de notre template, créé trois variantes de posts LinkedIn avec ma voix, et compilé le tout dans un seul document de sortie avec des sections clairement étiquetées.

Quatorze minutes. J'ai passé la plupart de ce temps à relire la sortie, pas à la créer.

Maintenant, multiplie ça par chaque workflow répétable dans une entreprise. Séquences de prospection commerciale. Procédures d'escalade du support client. Documents d'exigences produit. Synthèses de rapports financiers. Revues de contrats juridiques. Chacun peut être capturé comme un skill, regroupé dans un plugin, et déclenché par une commande.

C'est cette multiplication qui a effrayé le marché. Et honnêtement ? Le marché n'a pas tort d'être effrayé.

L'événement d'extinction SaaS auquel personne n'est préparé

C'est ici que je dois être prudent, parce que le take à chaud s'écrit tout seul et le take à chaud est faux. Le take à chaud c'est « le SaaS est mort. » Le SaaS n'est pas mort. Mais le modèle économique SaaS — facturer 15-150 $/mois par utilisateur pour un outil mono-fonction avec une jolie interface — fait face à un défi existentiel qu'il n'a pas vu depuis que le cloud computing a tué le logiciel on-premise.

Les chiffres racontent l'histoire. Salesforce a chuté de 8 % en un seul jour après l'annonce des plugins. ServiceNow a perdu 6 %. Adobe a lâché 5 %. HubSpot, Asana, Monday.com — tous ont pris des coups significatifs. Ce ne sont pas des entreprises éphémères. Ce sont les piliers de la stack logicielle moderne. Et le marché price un futur où leur proposition de valeur principale — être l'interface entre un humain et un processus métier — se fait absorber par un agent IA.

Je surveille ce pattern de près parce que je construis du logiciel pour gagner ma vie. Quand j'audite la stack tech d'un client, je trouve typiquement 15-25 abonnements SaaS. La plupart des employés en utilisent activement peut-être cinq. Le reste, ce sont des abonnements zombies qui persistent parce que les coûts de migration sont élevés et que personne ne veut être la personne qui annule un outil dont quelqu'un pourrait avoir besoin.

Les plugins Cloud Co-work changent ce calcul de manière brutale. L'agent IA devient l'interface universelle. Tu parles à un seul système. Ce système se connecte à tout. Les outils individuels existent toujours en arrière-plan — tu as toujours besoin d'une base de données, tu as toujours besoin de stockage fichiers, tu as toujours besoin d'une infrastructure de livraison email — mais la couche côté humain passe de quinze UI différentes à une seule interface conversationnelle.

Je ne fais pas une prédiction ici. Je décris quelque chose que je vis déjà. Le mois dernier, j'ai annulé trois abonnements SaaS parce que les plugins Cloud Co-work les ont rendus redondants. Pas parce que les plugins répliquaient chaque fonctionnalité — ce n'était pas le cas. Mais parce qu'ils répliquaient les fonctionnalités que j'utilise vraiment, ce qui s'avère être environ 20 % de ce pour quoi je payais.

Cette dynamique 80/20, c'est le vrai coup de couteau. La plupart des revenus SaaS proviennent de fonctionnalités que les utilisateurs ne touchent jamais. Quand l'agent IA gère les 20 % dont les gens ont réellement besoin, la justification de l'abonnement s'effondre. Et elle s'effondre vite.

Mais — et c'est la nuance que les prophètes de malheur ratent — les entreprises SaaS intelligentes ont un chemin de survie. J'y viendrai. C'est en fait une opportunité significative pour celles qui bougent assez vite.

Construire ton premier plugin : le guide pratique que personne d'autre n'écrit

Bon, assez d'analyse. Laisse-moi te montrer comment ça marche concrètement, parce que l'écart entre « comprendre les plugins conceptuellement » et « avoir un plugin fonctionnel qui te fait gagner des heures » est plus petit que tu ne le penses. J'ai construit mon premier plugin en environ quarante minutes, et je vais te guider à travers le processus que j'aurais aimé que quelqu'un documente pour moi.

Étape 1 : Identifie ton workflow à plus haute friction

Ne commence pas par quelque chose d'ambitieux. Commence par le workflow qui t'agace le plus — celui où tu te dis « je n'arrive pas à croire que je fais encore ça manuellement » au moins une fois par semaine. Pour moi, c'était le repurposing de contenu. J'écris un article de blog long format, et ensuite je dois créer un post LinkedIn, un thread Twitter, une intro de newsletter email, et un plan d'infographie à partir du même matériau source. Cinq sorties pour une entrée. Cinq outils différents. Cinq exigences de formatage différentes.

Étape 2 : Documente le workflow en langage courant

Ouvre un fichier markdown et décris ton processus comme si tu l'expliquais à un stagiaire malin le premier jour. Inclus les inputs (avec quels matériaux bruts tu commences ?), la logique de transformation (quelles décisions tu prends à chaque étape ?), les standards de qualité (qu'est-ce qui fait un bon output vs. un médiocre ?) et des exemples de sortie.

C'est à cette étape que la plupart des gens coupent les coins, et ça se voit dans leurs résultats. Plus ta description de skill est spécifique, mieux Cloud Co-work performe. N'écris pas « créer un post LinkedIn. » Écris « créer un post LinkedIn qui s'ouvre avec une accroche contre-intuitive, fait 150-200 mots, utilise des paragraphes courts de 1-2 phrases, inclut un point de données spécifique ou une anecdote personnelle tirée du matériau source, et se termine par une question qui génère des commentaires. »

Étape 3 : Crée ton fichier skill

Voici la structure que j'utilise pour chaque skill :

# Skill: [Name]

## Purpose
[One sentence describing what this skill does]

## Input Requirements
- [What the skill needs to work with]
- [Format specifications]

## Process
1. [Step-by-step instructions]
2. [Include decision points: "If X, then Y. If Z, then W."]
3. [Reference any attached documents or templates]

## Output Format
[Exact format the output should follow]

## Quality Criteria
- [Specific, measurable standards]
- [Examples of good vs. bad output]

## Reference Materials
[Links to or embeds of example outputs, style guides, templates]

Astuce de pro : Inclus 3 à 5 exemples de tes meilleurs travaux comme matériau de référence. Le pattern matching de Cloud Co-work s'améliore drastiquement quand il dispose d'exemples concrets plutôt que de descriptions abstraites. J'ai joint mes posts LinkedIn les plus performants triés par taux d'engagement, et le saut de qualité entre « pas d'exemples » et « cinq exemples » était le jour et la nuit.

Étape 4 : Configure les connections

C'est la partie qui semblait intimidante mais qui s'est avérée simple. L'interface de connection de Cloud Co-work te permet d'autoriser l'accès à des outils externes via des flux OAuth — similaire à comment tu connecterais n'importe quelle app tierce. La différence, c'est le cloisonnement par département que j'ai mentionné plus tôt.

Pour mon plugin de contenu, j'ai connecté Google Docs (pour les matériaux sources), Buffer (pour la planification sociale), et ma plateforme email. Chaque connection m'a demandé de spécifier quel niveau d'accès le plugin nécessitait — lecture seule, lecture-écriture, ou accès complet. Commence avec les permissions minimales dont tu as besoin. Tu pourras toujours élargir plus tard.

Étape 5 : Définis tes commands

Les commands sont l'endroit où les skills individuels deviennent des workflows automatisés. La syntaxe est simple — tu crées essentiellement des slash commands qui enchaînent les skills ensemble.

/repurpose-content
  → Skill: Extract key insights from source document
  → Skill: Generate LinkedIn post
  → Skill: Generate Twitter thread
  → Skill: Generate newsletter intro
  → Skill: Generate infographic outline
  → Output: Compiled document with all formats

Chaque skill dans la chaîne reçoit la sortie du skill précédent plus le matériau source original. Cette accumulation de contexte est ce qui fait que les workflows enchaînés semblent cohérents plutôt que fragmentés.

Étape 6 : Teste, itère et affine

Lance ton plugin sur trois inputs différents. Pas un. Trois. Le premier test te montre si le flux de base fonctionne. Le deuxième test révèle les cas limites. Le troisième test expose les problèmes de cohérence.

Après mon premier test, j'ai réalisé que mon skill LinkedIn écrivait des posts trop longs — 300 mots au lieu de ma cible de 200. J'ai ajouté une contrainte stricte au fichier skill : « La sortie doit faire 150-200 mots. Si le premier brouillon dépasse 200 mots, réduire automatiquement en supprimant la phrase la plus faible et en resserrant les transitions. » Ça a réglé le problème.

L'itération n'est pas un échec. C'est du calibrage. Prévois trente minutes pour l'affinage et tu te retrouveras avec un plugin qui fonctionne vraiment.

Les trois types de plugins qui vont créer une nouvelle économie

Voici ce que la plupart des commentaires ratent à propos des implications business des plugins Cloud Co-work. Ce n'est pas juste une question de productivité individuelle. C'est l'émergence de trois catégories distinctes de plugins, chacune créant des dynamiques économiques différentes.

Les plugins construits par Entropic sont la base. Open-source, couvrant les fonctions business courantes — ventes, support, gestion produit, finance, juridique. Ils sont délibérément génériques, conçus pour gérer 70 % d'un workflow standard dès l'installation. Vois-les comme les applications par défaut pré-installées sur ton téléphone. Assez bien pour la plupart des gens. Personnalisées pour personne.

Les plugins de fournisseurs tiers sont là où ça devient intéressant d'un point de vue business. Imagine Salesforce — au lieu de combattre Cloud Co-work, ils construisent un plugin Salesforce qui permet à Cloud Co-work d'interagir avec la couche de données et les fonctionnalités propriétaires de Salesforce à travers l'agent. L'IA gère l'interface. Salesforce gère l'infrastructure de données et la logique métier qui ont pris vingt ans à construire. Leur modèle d'abonnement passe de « payer pour l'UI » à « payer pour le moteur. » C'est en fait une position plus défendable.

J'ai déjà vu des startups en phase initiale pivoter l'intégralité de leur business model vers le développement de plugins. Une entreprise que je conseille construisait un outil autonome d'intelligence concurrentielle. Après l'annonce des plugins, ils ont abandonné l'UI entièrement et reconstruit leur moteur d'analyse central comme un plugin Cloud Co-work. Leur raisonnement : pourquoi passer deux ans et 2 M$ à construire une interface quand tu peux te brancher sur une interface qui a déjà des millions d'utilisateurs ?

Les plugins custom sont la longue traîne, et potentiellement les plus transformateurs. N'importe quelle entreprise peut créer des plugins qui encodent ses workflows spécifiques, ses connaissances institutionnelles et ses avantages concurrentiels. Un cabinet d'avocats peut construire un plugin qui rédige des contrats dans leur style spécifique, en référençant leur bibliothèque de clauses. Une entreprise e-commerce peut construire un plugin qui génère des descriptions produit correspondant à leur voix de marque et leurs exigences SEO. Une agence marketing peut packager sa méthodologie de planification de campagne comme plugin et la licencier à ses clients.

L'économie des plugins custom va ressembler beaucoup aux premiers jours des thèmes WordPress et des apps Shopify. Certains seront gratuits. D'autres commanderont des prix premium. Les meilleurs généreront un revenu passif pour leurs créateurs.

Je construis déjà trois plugins custom pour mon propre workflow, et j'envisage d'en packager deux comme produits. Celui qui automatise mon processus de repurposing de contenu à lui seul me fait gagner environ six heures par semaine. Si je facturais ne serait-ce que 29 $/mois pour ça comme plugin autonome — ce qui est pas cher comparé aux outils qu'il remplace — les économiques fonctionnent à merveille.

Les vrais problèmes dont personne ne veut parler

Écoute, j'ai passé les deux mille derniers mots à peindre un tableau optimiste, et j'y crois en grande partie. Mais je te rendrais un mauvais service si je ne parlais pas des vrais problèmes que j'ai rencontrés, parce qu'ils sont réels et ils t'affecteront toi aussi.

Le piège du « suffisamment bon » est dangereux. La sortie générée par les plugins est impressionnante — peut-être 80-85 % aussi bonne que ce qu'un humain compétent produit. Pour beaucoup de cas d'usage, c'est suffisant. Pour le repurposing de contenu, les brouillons rapides et la documentation interne, je prends 85 % de qualité à 10 % du temps d'investissement sans hésiter. Mais je me suis surpris à laisser ce standard du « suffisamment bon » se glisser dans du travail qui exige l'excellence. Une étude de cas orientée client. Un article technique où la précision compte. Une proposition commerciale où un seul mauvais chiffre pourrait coûter un deal.

La discipline requise, c'est de savoir quand 85 % c'est bien et quand ça ne l'est pas. J'ai commencé à coder mes tâches par couleur : vert pour « le plugin peut gérer ça de bout en bout, » jaune pour « le plugin rédige, je relis et j'édite, » et rouge pour « je dois faire ça moi-même. » Ce cadre m'a sauvé de publier du travail que je regretterais.

Les limitations de fenêtre de contexte sont réelles et frustrantes. Cloud Co-work est puissant, mais il travaille toujours dans des contraintes de tokens. Quand j'ai essayé de lui fournir un document de spécification produit de 40 pages et de lui demander de générer une documentation technique complète, il commençait à perdre des détails des premières pages au moment d'arriver à la section implémentation. J'ai dû découper le document en sections et les traiter individuellement, ce qui a brisé l'expérience fluide « une commande, sortie complète ».

Entropic travaille clairement là-dessus — les fenêtres de contexte ne cessent de s'agrandir — mais en ce moment, les workflows complexes avec de gros inputs nécessitent des stratégies de découpage qui ajoutent de la friction.

La portabilité des plugins reste pénible. En l'état actuel, partager des plugins signifie exporter un fichier zip ou pousser vers un dépôt GitHub et faire en sorte que l'autre personne l'importe. Il n'y a pas de marketplace. Pas d'installation en un clic. Pas de gestion de versions. Entropic a dit qu'une marketplace arrivait, ainsi que des outils de partage internes pour les équipes. Mais on n'y est pas encore, et l'écart entre « j'ai construit un plugin incroyable » et « mon équipe peut l'utiliser » est plus large qu'il ne devrait l'être.

Les implications de sécurité m'empêchent de dormir la nuit. Je dis ça en tant que quelqu'un qui dirige une pratique de cybersécurité. Quand tu donnes à un agent IA un accès via connection à ton CRM, ton email, ton outil de gestion de projet et ton stockage de fichiers — tu crées un point unique de compromission. Le cloisonnement par département aide. Le modèle de permissions OAuth aide. Mais la surface d'attaque reste préoccupante, surtout pour les entreprises qui manipulent des données sensibles. J'adorerais voir Entropic publier un document d'architecture de sécurité détaillé. En attendant, je reste prudent sur les connections que j'autorise.

Ma prédiction ? Ces problèmes seront résolus dans les 12-18 mois. Ce sont des problèmes d'ingénierie, pas des défauts de conception fondamentaux. Mais si tu adoptes les plugins aujourd'hui, tu dois être au courant.

À quoi ressemblent mes chiffres après soixante jours d'utilisation intensive des plugins

J'ai suivi mes propres métriques de manière obsessionnelle parce que je voulais savoir si les plugins apportent de vrais gains de productivité ou si l'effet de nouveauté gonflait ma perception. Voici les données brutes.

Temps passé sur la création de contenu : En baisse de 62 %. J'étais en moyenne à 4,5 heures par article long format en incluant le repurposing. Maintenant je suis en moyenne à 1,7 heure, dont la majeure partie est de l'édition et de la relecture qualité.

Dépenses SaaS : En baisse de 387 $/mois. J'ai annulé les abonnements de trois outils de contenu, une plateforme de planification sociale, et un tableau de bord analytique que les plugins Cloud Co-work ont remplacé fonctionnellement.

Volume de production : En hausse de 3x. Je publie plus de contenu sur plus de canaux sans travailler plus d'heures. Les mêmes semaines de 50 heures, une distribution d'effort différente.

Cohérence de la qualité : Celle-ci m'a surpris. Avant les plugins, la qualité de mon contenu variait selon mon niveau d'énergie, quel jour de la semaine c'était, et combien de fois j'avais été interrompu. Les plugins produisent une base cohérente que j'élève ensuite par l'édition. Mes pires sorties se sont améliorées. Mes meilleures sorties sont restées à peu près les mêmes.

Temps pour mesurer le ROI : Environ deux semaines d'utilisation active avant que les gains deviennent évidents. La première semaine c'est l'installation et le calibrage. La deuxième semaine c'est quand la mémoire musculaire se met en place et tu arrêtes de penser à l'outil pour commencer à penser au travail.

La métrique qui me tient le plus à coeur — les heures facturables libérées pour du travail à plus haute valeur — s'est améliorée d'environ huit heures par semaine. Ça se traduit directement en revenu quand tu gères un cabinet de conseil. Pour un employé, ça se traduit soit par en faire plus, soit par faire la même quantité avec moins de stress. Les deux ont de la valeur.

Les gains rapides viennent du remplacement de tes workflows les plus répétitifs en premier. Les gains à long terme viennent de la construction de plugins qui encodent tes connaissances institutionnelles si bien que les nouveaux membres de l'équipe peuvent produire un travail de niveau expert dès leur première semaine. C'est dans cette deuxième catégorie que vivent les rendements composés, et je commence à peine à l'explorer.

Que se passe-t-il quand chaque employé a son propre agent IA

Soixante jours d'utilisation des plugins ont fait évoluer ma réflexion sur quelque chose de bien plus grand que la productivité personnelle.

On se dirige vers un monde où l'employé moyen — pas le développeur, pas le power user, la personne lambda qui galère actuellement avec les formules Excel — dispose d'un agent IA configuré qui comprend son rôle, ses outils, ses workflows et ses préférences. Un agent qui s'améliore plus tu l'utilises parce que ses skills et plugins accumulent du savoir institutionnel au fil du temps.

Ce n'est pas une amélioration de la productivité. C'est une restructuration du marché du travail. Et les entreprises qui comprendront comment intégrer les plugins dans leurs opérations en premier auront un avantage structurel qui se compose mensuellement.

Je reviens sans cesse à une conversation que j'ai eue avec une amie non-technique qui dirige une agence marketing de vingt personnes. Elle se noyait dans la prolifération d'outils — son équipe utilisait dix-neuf produits SaaS différents. Elle m'a dit qu'elle n'arrivait pas à recruter assez vite pour suivre la demande client. Je l'ai aidée à mettre en place trois plugins Cloud Co-work : un pour l'onboarding client, un pour la planification de campagne, et un pour le reporting. Elle m'a rappelé une semaine plus tard. « Mon équipe actuelle vient de devenir 40 % plus rapide. Je n'aurai peut-être pas besoin de pourvoir ces deux postes. »

C'est une petite agence. Multiplie ça par des millions.

Je n'ai pas de réponse nette sur ce que ça signifie pour l'emploi, pour l'économie SaaS, pour la façon dont on pense le logiciel lui-même. Ce que je sais, c'est que le modèle plugin — modulaire, composable, accessible aux non-développeurs — est le mécanisme qui fait passer l'IA de « démo intéressante » à « changement structurel. » Et le changement structurel n'attend pas que tu sois prêt.

Alors voici ce que je te conseille de faire avant le week-end. Choisis un workflow. Le plus agaçant, répétitif, et usant de ta semaine. Passe quarante minutes à construire un plugin pour ça. Pas parce que ce sera parfait du premier coup — ça ne le sera pas. Mais parce que l'acte de le construire va recâbler ta façon de penser chaque autre workflow de ta vie. Tu vas commencer à voir des opportunités de plugins partout. Et ce changement de perception vaut plus que n'importe quel plugin individuel que tu construiras jamais.

Le modèle SaaS n'est pas mort. Mais l'hypothèse que les humains ont besoin de quinze interfaces différentes pour faire leur travail ? Cette hypothèse vient de recevoir une date d'expiration. Et le compte à rebours a déjà commencé.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io