Divinci AI rejoint le Cloudflare Workers Launchpad Cohort #6

Nous sommes ravis de partager que Divinci AI a été accepté dans le Cloudflare Workers Launchpad Cohort #6 ! Ce programme d’accélération soutient les startups innovantes construisant sur la plateforme d’edge computing de Cloudflare, et nous sommes honorés de faire partie de cette cohorte exceptionnelle.

Pourquoi Cloudflare Workers ?

Chez Divinci AI, nous construisons la prochaine génération d’outils de collaboration IA d’entreprise en mettant l’accent sur la fiabilité, la sécurité et les performances. La plateforme d’edge computing de Cloudflare a été essentielle pour atteindre ces objectifs, nous permettant de fournir des capacités IA sophistiquées avec une latence minimale à travers le monde.

Déploiement global en périphérie permettant l'IA à la vitesse de la pensée

Notre infrastructure alimentée par Cloudflare

Nous avons architecturé toute notre plateforme autour de la suite de produits Cloudflare, créant une infrastructure puissante et évolutive qui prend en charge nos pipelines RAG (génération augmentée par récupération) avancés :

Cloudflare Workers & Workflows

L’épine dorsale de notre plateforme, Cloudflare Workers alimente notre couche de calcul sans serveur, gérant des millions de requêtes avec des temps de réponse inférieurs à la milliseconde. Nous utilisons Cloudflare Workflows pour orchestrer des pipelines RAG complexes en plusieurs étapes qui récupèrent, traitent et synthétisent intelligemment les informations provenant de plusieurs sources.

D1 pour le stockage de morceaux RAG

Nous exploitons Cloudflare D1, leur base de données SQL distribuée, pour stocker et interroger nos morceaux RAG de manière efficace. L’architecture en périphérie de D1 garantit que les morceaux de documents sont stockés près de nos utilisateurs, réduisant considérablement la latence de récupération et améliorant la qualité de nos réponses IA.

Vectorize pour la recherche sémantique

Cloudflare Vectorize sert comme l’une de nos options de base de données vectorielle, permettant une recherche sémantique ultra-rapide parmi des millions d’embeddings de documents. Cela permet à nos systèmes IA de trouver le contexte le plus pertinent pour toute requête, quelle que soit sa formulation.

Workers AI pour les modèles open-source

Nous intégrons Cloudflare Workers AI pour fournir l’accès à des modèles de langage open-source de pointe depuis Hugging Face, incluant Llama 3, Mistral et d’autres modèles state-of-the-art. Cela donne à nos clients d’entreprise la flexibilité de choisir le bon modèle pour leurs cas d’usage spécifiques tout en maintenant la confidentialité et le contrôle des données.

R2 pour le stockage multimédia

Cloudflare R2 gère tous nos besoins de traitement audio, vidéo et de téléchargement de fichiers utilisateur. Avec zéro frais de sortie et des API compatibles S3, R2 fournit un stockage d’objets de niveau entreprise qui évolue de manière transparente avec notre base de clients croissante.

API Shield pour la sécurité

Alors que nous nous préparons à lancer nos API publiques, Cloudflare API Shield fournit une protection essentielle contre les abus, la limitation de débit et la validation de schéma. Cela garantit que nos API restent sécurisées, performantes et fiables pour tous nos partenaires d’intégration.

Expérimentation avec Cloudflare Containers

Nous explorons également Cloudflare Containers alors que nous travaillons à déplacer toute notre infrastructure pour qu’elle soit principalement basée sur Cloudflare. Cela nous permettra d’exécuter des charges de travail encore plus complexes en périphérie tout en maintenant les performances et la fiabilité attendues par nos clients.

Comment Divinci utilise concrètement Cloudflare — la stack de production

Nous avons évité ici le piège de la « prose marketing aux saveurs Cloudflare ». Ce qui suit, c’est la stack réelle telle qu’elle est livrée dans notre monorepo : 29 Workers en production, 3 Worker Workflows, 5 modèles Workers AI, 4 buckets R2, 6 types de Queues, Hyperdrive sur Postgres, des Containers adossés à des Durable Objects pour le PDF et l’audio, et 36 tail consumers qui transmettent des logs structurés vers l’observabilité. Les pièces portent le nom de leurs vrais bindings et domaines de route afin que les ingénieurs qui lisent ceci puissent grep dessus.

Couche 1 — Cinq Workers principaux à l’edge

Chaque requête HTTP atterrit sur l’un de cinq Workers à domaine personnalisé :

• divinci-api sur api.divinci.app — la frontière REST : auth, validation JWT, résolution de routes, fan-out vers les workers internes. Les bindings incluent le bucket R2 FILES, le namespace KV CACHE, la base D1 des doc-elements, Workers AI, Hyperdrive, Analytics Engine et quatre Queues nommées. C’est le worker qui voit la requête en premier.
• web-client-r2-server sur chat.divinci.app — le frontend statique, servi directement depuis R2 via un Worker léger qui gère la réécriture côté Worker et le routage dans la SPA.
• divinci-agent — l’orchestrateur de composition des réponses. Tire le contexte depuis D1 + KV + R2, décide quel modèle Workers AI appeler (ou s’il faut déléguer à une API externe via Hyperdrive), compose la réponse.
• chunks-workflow sur rag-workflow.divinci.app — le point d’entrée Worker Workflows ; appelé chaque fois qu’un pipeline RAG de longue durée doit être déclenché.
• connector-sync-worker — le worker d’ingestion externe qui synchronise depuis Dropbox / Drive / connecteurs tiers similaires vers le pipeline RAG.

Il y a 24 autres workers derrière ces cinq-là (tail consumers, microservices internes) — les cinq ci-dessus sont ce qui est exposé à l’internet public.

Couche 2a — Worker Workflows (trois pipelines async multi-étapes)

Cloudflare Workflows a remplacé nos anciens job-runners basés sur Durable Objects l’an dernier. Trois workflows sont en production aujourd’hui, tous utilisant le pattern de checkpoint step.do("name", async () => {…}) pour que chaque étape soit retentée indépendamment en cas d’échec, sans rejouer tout le pipeline :

• ReindexWithVersionWorkflow — re-embed un corpus client entier lorsque la version du modèle d’embedding change. Versionne l’index résultant pour qu’un rollback se fasse par un simple échange de binding.
• BrowserExtractionWorkflow — extrait le texte des documents téléversés via le container Durable Object openparse-cf, puis chunke + met en queue les chunks pour embedding.
• AudioToRagWorkflow — transcrit l’audio avec Workers AI Whisper, exécute la diarisation des locuteurs via le Container audio-services, chunke la transcription et met en queue pour embedding.

Les trois sont déclarés dans wrangler.toml comme suit :

[[env.production.workflows]]
name = "reindex-with-version"
binding = "REINDEX_WITH_VERSION"
class_name = "ReindexWithVersionWorkflow"

Couche 2b — Six Queues, calibrées pour la limite single-writer de D1

Le travail asynchrone passe par six Queues nommées, chacune avec max_batch_size, max_concurrency et max_retries calibrés selon le goulot d’étranglement du service en aval. Les queues chunking et api-jobs tournent à batch 10 / concurrence 5 car elles écrivent dans D1 (dont l’écrivain par shard est mono-thread) ; les queues vectorize et reindex tournent plus chaudes à 25/10 parce qu’elles appellent des API d’embedding externes. La queue d1-sync sérialise les écritures vers les shards D1 par vecteur pour que deux workflows ne courent pas après la même ligne.

La leçon qu’on aurait aimé apprendre plus tôt : les Queues sont la seule chose qui maintient honnête un setup D1 shardé par client. Sans elles, un seul locataire avec un gros upload affame tous les autres sur le même shard jusqu’au timeout de la requête.

Couche 3 — R2, D1, KV et Hyperdrive

La couche de stockage est répartie sur quatre primitives, chacune choisie pour un pattern d’accès différent.

R2 (quatre buckets par environnement) — les bindings sont FILES (documents RAG), AUDIO_FILES (audio source pour les pipelines de transcription), PUBLIC_UPLOADS (pièces jointes du chat servies via des endpoints d’URL signées) et TEMP_UPLOADS (la zone d’atterrissage des uploads présignés). Les frais d’egress à zéro sont la raison d’affiche, mais la plus profonde est que le même Worker peut signer une URL, accepter un upload de plusieurs Mo, lancer le BrowserExtractionWorkflow et servir le contexte RAG résultant — le tout sans sortir de l’edge Cloudflare.

D1 (shardé par locataire) — chaque client a sa propre base D1, avec chunk + métadonnées dans des tables normales et une table virtuelle FTS5 pour la recherche texte-uniquement. Le sharding par client était la seule façon d’éviter le goulot single-writer sur les locataires chauds. Le coût est qu’on gère un fan-out à travers les shards dans la couche applicative ; le bénéfice est qu’un pic d’un locataire ne peut pas affamer les lectures d’un autre.

KV (trois namespaces) — CACHE héberge les résultats de validation JWT et la config locataire ; EMBEDDING_CACHE est la map content-hash → bytes-d’embedding avec un TTL de 30 jours (c’est la plus grosse réduction de coût que nous ayons faite — cacher les embeddings par hash de contenu a diminué la facture quotidienne de l’API d’embedding d’un ordre de grandeur) ; VECTORIZE_CACHE est la couche wrapper que le worker vectorize-cache utilise pour mémoriser les lookups vectoriels.

Hyperdrive — pooling de connexions Postgres à l’edge. Le binding HYPERDRIVE permet à un Worker d’ouvrir une connexion Postgres sans payer le coût du handshake TCP + auth à chaque requête. Nous l’utilisons pour la petite tranche de données relationnelles (état d’abonnement, ACL au niveau organisation) qui ne rentre pas dans le modèle shardé de D1.

Couche 4a — Workers AI (cinq modèles en production)

Workers AI est la couche d’inférence sur la plateforme ; nous l’utilisons là où le modèle est assez petit pour qu’un aller-retour vers un fournisseur externe ne vaille pas la latence ou le coût :

Pour la génération à l’échelle frontière (classe Claude, GPT-4) nous routons toujours vers des fournisseurs externes via Hyperdrive — le catalogue Workers AI grandit mais n’inclut pas encore les plus grands modèles dont nous avons besoin pour les requêtes les plus difficiles.

Couche 4b — Containers, Email, Analytics, Tail Consumers

Les Containers Durable Object sont la pièce la plus récente de la stack : des images Docker complètes tournant sur le runtime Workers, scopées par instance DO. Nous en exécutons deux :

• openparse-cf est un parser PDF en Python empaqueté en Container, appelé par le BrowserExtractionWorkflow pour le chunking de documents.
• audio-services-container exécute ffmpeg + pyannote-audio pour la diarisation des locuteurs, appelé par l’AudioToRagWorkflow. Tier mémoire standard-2 (6 Go) pour que les modèles les plus lourds se chargent sans OOM.

Workers Email — un Worker de notifications transactionnelles envoie les emails produit, et un Worker de routage gère le courrier entrant à email.divinci.app/verified-emails. Les deux utilisent la primitive Email Routing de Cloudflare plutôt qu’une API email externe.

Analytics Engine — un dataset Workers Analytics Engine sert de sink d’événements structurés pour l’analytics produit. Tout ce que nous aurions auparavant envoyé à Segment/Amplitude atterrit ici d’abord, puis est forwardé en aval.

Tail Consumers (36 workers) — chaque worker de production a sa liste tail_consumers peuplée d’un consumer *_tail dédié. Chaque consumer parse les logs d’invocation du Worker et forwarde les événements structurés vers notre pipeline d’observabilité. C’est ce fanout qui rend la topologie microservices à huit workers débogable.

Déclencheurs Cron — la production exécute un job de nettoyage des orphelins toutes les 30 minutes ; le stage tourne toutes les 10 minutes pour un feedback plus serré pendant qu’on itère sur la logique de nettoyage.

Une note sur Vectorize — ce que nous n’utilisons pas, et pourquoi

Nous avons évalué Cloudflare Vectorize pendant la migration et nous ne l’avons finalement pas adopté comme magasin vectoriel principal. La décision n’avait rien à voir avec Vectorize lui-même — il s’est considérablement amélioré au cours de 2025–2026. La raison pour laquelle nous avons atterri sur D1 FTS5 + un service d’embedding externe était que notre architecture de récupération est hybride (lexicale + sémantique avec un re-ranker calibré au-dessus), et FTS5 dans D1 nous donnait la moitié lexicale gratuitement, sur le même shard que les métadonnées du document. Ajouter Vectorize aurait introduit un second modèle de cohérence — un index séparé qui doit rester en sync avec D1 — pour une amélioration marginale du recall aux volumes que nous opérons. Le nom du namespace KV VECTORIZE_CACHE est un reste de la période d’évaluation ; le worker derrière cache désormais des lookups d’embeddings, pas des résultats Vectorize.

Si notre modèle de récupération bascule vers une récupération dense-uniquement à très grande échelle, Vectorize est la prochaine étape naturelle. Une réponse honnête vaut mieux qu’une affirmation marketing.

Ce que cela signifie pour nos clients

Faire partie de l’accélérateur Workers Launchpad signifie que nous aurons une collaboration encore plus approfondie avec l’équipe d’ingénierie de Cloudflare, un accès anticipé aux nouvelles fonctionnalités et les ressources pour repousser les limites du possible avec l’edge computing et l’IA.

Pour nos clients, cela se traduit par :

• Réponses IA plus rapides avec un déploiement global en périphérie
• Fiabilité améliorée grâce au SLA de disponibilité de 99,99% de Cloudflare
• Meilleure confidentialité des données avec traitement en périphérie
• Fonctionnalités innovantes alimentées par les produits Cloudflare de pointe
• Infrastructure évolutive qui grandit avec vos besoins

Perspectives

Nous sommes incroyablement enthousiastes à propos de ce partenariat et des opportunités qu’il apporte. Alors que nous continuons à construire l’avenir de la collaboration d’entreprise alimentée par l’IA, la plateforme de Cloudflare restera au cœur de notre infrastructure, nous permettant d’offrir des expériences exceptionnelles aux équipes du monde entier.

Innovation à travers les âges : Construire l'avenir avec des principes intemporels

Vous voulez en savoir plus sur la façon dont Divinci AI peut transformer le flux de travail IA de votre équipe ? Demandez une démo pour voir notre plateforme en action.

À propos du Cloudflare Workers Launchpad

Le Workers Launchpad est le programme de startups de Cloudflare qui fournit du financement, un support technique et des ressources de mise sur le marché aux entreprises construisant sur la plateforme Workers. En savoir plus sur la cohorte #6 et les autres entreprises innovantes rejoignant ce programme.