De nombreuses équipes ont des besoins qui ne justifient pas vraiment une application : un comparateur pour examiner des propositions, un registre de décisions ou un inventaire qui ne servira que pendant une migration. On y répond généralement avec ce que l’on a sous la main. Construire quelque chose soi-même oblige à décider où l’héberger, comment conserver les données et qui peut y accéder. Parfois, ce travail autour pèse plus lourd que l’outil lui-même.
Dans Quand le logiciel dure aussi longtemps que le problème, nous parlions d’applications générées pour une tâche précise. Mais écrire le code n’en est qu’une partie : il leur faut un endroit où fonctionner, conserver ce que nous faisons et être partagées. Cloudflare OS propose cet endroit. Chez Codin, nous l’avons déployé pour explorer ce qu’il permet de faire.
Un environnement de travail que l’on peut aussi modifier
Cloudflare OS est un projet ouvert de Cloudflare qui réunit des agents d’IA, de petites applications et un accès contrôlé à des services externes. Il s’utilise depuis le navigateur et peut être déployé sur sa propre installation.
La comparaison proposée par Cloudflare aide à le comprendre : imaginez une suite bureautique où chaque fichier pourrait être une application sur mesure. Au lieu de toujours choisir entre un document, un tableur ou une présentation, vous pourriez créer un outil avec les champs, les vues et les actions dont vous avez besoin. OS appelle ces applications des gadgets, que l’on peut adapter et partager.
La différence se voit sur un exemple simple. Supposons que nous voulions comparer les propositions de plusieurs fournisseurs. Un tableau rassemble les données, mais nous avons peut-être aussi besoin de signaler des doutes, de conserver la justification de chaque évaluation et de n’afficher que les différences pertinentes. Une application à nous permettrait de réunir tout ce parcours sur un même écran. L’intérêt d’OS est d’offrir un environnement commun pour construire des outils de ce type, sans préparer une infrastructure distincte pour chacun.
Exemple illustratifD’une idée à un outil
Conversation
Je veux comparer trois propositions de fournisseurs : délai, périmètre et support.
Je prépare un comparateur avec une colonne par proposition et une ligne par critère.
Ajoute les conditions de chacune et permets de filtrer par support inclus.
Décrire : la demande part d’une tâche concrète. Il suffit d’expliquer ce qu’il faut comparer et selon quels critères.
Construire : l’assistant propose une première version du gadget. Ici, c’est une ébauche avec trois fournisseurs fictifs, leurs délais et leur périmètre.
Adapter : un nouveau besoin apparaît pendant l’examen. L’outil ajoute une ligne de conditions et un filtre qui relègue au second plan la proposition sans support inclus.
De la demande d’un outil au travail avec lui
L’assistant intégré permet de décrire un gadget et de demander des modifications. La conversation peut se poursuivre une fois la première version créée : ajouter une vue, changer la présentation d’un résultat ou intégrer une action. Le code de l’outil reste disponible pour continuer à le modifier.
Cela change notre rapport à une petite application. Pour revenir au comparateur, découvrir en cours d’examen qu’il manque l’enregistrement d’une condition du fournisseur pourrait donner lieu à une modification de l’outil. Nous n’aurions plus à faire entrer toute la tâche dans les possibilités du premier écran. Il faudrait bien sûr vérifier que cette modification préserve les données et fait ce que nous attendons.
Dans OS, la conversation et l’application cohabitent dans le même espace. À gauche se trouvent la demande et son historique ; à droite, nous pouvons utiliser le gadget, ouvrir ses fichiers ou consulter les services qui lui sont connectés. Voici les trois vues de notre installation :
Captures réellesUn gadget, trois façons de travailler
1 · La demande reste visible. Dans ce cas : un CRM avec pipeline, suivi et opportunités issues de Radar. En dessous, il est consigné que les modifications ont été acceptées.
2 · L’application s’utilise à côté. L’onglet App ouvre le gadget : on peut consulter le tableau de bord et travailler avec ses données sans quitter l’espace.
1 · Les fichiers sont accessibles. Code rassemble l’interface et la logique du gadget. Un onglet suffit pour passer de l’application à son implémentation.
2 · Les règles peuvent être examinées. On voit ici les étapes du CRM et le contexte qu’il utilise. La conversation reste à côté pendant que nous inspectons le code.
1 · Les ressources du gadget ont leur propre panneau. Connections affiche le modèle disponible et le nom sous lequel le code l’utilise : LUNA. Cette connexion permet de demander une analyse depuis le CRM.
Le CRM nous a permis de tester ce parcours avec des informations publiques importées depuis Codin Radar. C’est une première version, avec import manuel, mais elle réunit une application qui conserve ses données, un code que nous pouvons modifier et une connexion à l’IA pour analyser des opportunités.
L’exemple distingue aussi deux usages de l’IA. L’un aide à écrire l’outil ; l’autre accomplit une tâche à l’intérieur de celui-ci. Enregistrer une note ou changer une étape reste du logiciel conventionnel. L’application n’a pas besoin qu’un modèle la réimagine chaque fois que quelqu’un l’utilise.
Construire avec les outils que vous utilisez déjà
Lors de notre test, nous avons écrit le gadget avec Codex, depuis notre environnement habituel, puis nous l’avons installé via l’API d’OS. Cette API utilise Cap’n Web, une bibliothèque de Cloudflare permettant d’appeler des fonctions distantes depuis JavaScript. Le processus consistait à modifier le code, à le relire et à envoyer la nouvelle version.
Cette possibilité nous semble particulièrement utile pour les équipes techniques. Nous pouvons conserver l’éditeur, le modèle et la manière de relire le code avec lesquels nous travaillons déjà. OS devient le lieu où l’application s’exécute et conserve ses données, même si sa construction se fait en dehors de son assistant.
Elle permet aussi de répartir le travail. Une personne peut exposer ce dont elle a besoin et vérifier l’interface ; une autre peut se charger des parties qui demandent plus de soin. La conversation aide à préciser l’outil, et le code reste là lorsqu’il faut comprendre ou corriger son comportement.
Partager un outil ou réutiliser sa conception
OS distingue l’accès pour utiliser et l’accès pour construire. La personne qui reçoit le premier travaille avec l’application et ses fonctions ; celle qui reçoit le second peut aussi modifier le code. Utiliser ne signifie pas seulement consulter : un gadget peut permettre d’enregistrer des informations ou de demander une analyse sans donner accès à son développement.
Il existe une autre façon de partager, tout aussi intéressante : les blueprints. Ce sont des modèles d’applications complètes. Ils permettent à une autre personne de créer sa propre copie du gadget, avec son propre stockage et ses propres connexions, sans emporter l’historique, les données enregistrées ni les identifiants de l’instance d’origine.
La différence est concrète. Une équipe pourrait travailler ensemble sur le même inventaire de migration. Une autre pourrait réutiliser sa conception pour une migration différente, avec ses propres systèmes et responsables. Dans le premier cas, elles partagent le travail ; dans le second, un outil qui leur évite de repartir de zéro.
Exemple illustratifPartager le travail ou la conception
Lucíamême instanceinstance d’origine
Migration Nord
- Serveur de messagerie Lucía : vérifier le DNS
- Base clients Andrés : exportée
- VPN du bureau Lucía : en attente
Andrésmême instancenouvelle copie
Migration Nord
- Serveur de messagerie Lucía : vérifier le DNS
- Base clients Andrés : exportée
- VPN du bureau Lucía : en attente
Migration Sud
- Portail fournisseurs Andrés : demander l’accès
- Stockage de fichiers
- Imprimantes de l’étage Andrés : inventorier
Travailler ensemble : les deux personnes ouvrent le même outil et voient les mêmes données, si bien que ce que l’une note apparaît pour l’autre. Avec l’accès pour utiliser, elles peuvent enregistrer des informations ; modifier le code exige l’accès pour construire.
Créer une copie : un blueprint décrit l’application complète et permet de créer une autre instance, avec son propre stockage et ses propres connexions. La conception est réutilisée ; l’historique, les données et les identifiants de l’original ne passent pas dans la copie.
Les connexions externes ont également leur place dans la proposition. OS utilise des Gatekeepers, des composants qui encadrent l’accès des agents et des gadgets à des ressources précises. Cela suppose de configurer les intégrations correspondantes : déployer OS ne connecte pas automatiquement tous les systèmes de l’entreprise.
Ce qui mérite son propre outil
Cloudflare présente OS comme un projet encore en développement. Notre expérience est elle aussi récente : nous avons testé une application, pas mesuré une évolution de la productivité de l’équipe. Et un outil maison demande toujours de la maintenance ; un produit établi peut mieux répondre à un processus qui dépend de nombreuses intégrations ou nécessite un support continu.
Il vaut néanmoins la peine de s’intéresser à cet espace de petites tâches que les outils génériques ne couvrent qu’à moitié. Un outil d’examen des propositions peut accompagner un processus récurrent. Un inventaire de migration n’aura peut-être de sens que pendant quelques semaines. Tous deux ont besoin d’une interface, de règles et de données qui se conservent, même si leur durée de vie diffère.
Ce que nous voulons continuer à explorer avec Cloudflare OS, c’est cette possibilité : disposer, déjà prêt, du lieu où ces outils peuvent vivre. Si chacun exige de lancer un projet entier, beaucoup ne sont même pas envisagés. Si une partie du travail est déjà réglée, la question peut se rapprocher de la tâche : ce que nous devons faire et quelle application nous aiderait à le faire.
