Présentation
Town, jeune société de San Francisco, a levé 108 millions de dollars lors d’une série B co‑dirigée par Forerunner Ventures et Menlo Ventures. Cette levée porte le total des fonds levés à 160 millions de dollars, incluant une série A de 55 M$ annoncée en juin. L’entreprise, fondée il y a deux ans par l’ancien CTO de Plaid, Jean‑Denis Greze, a rendu public son produit seulement quatre mois auparavant et affirme déjà générer plusieurs millions de dollars de revenu récurrent annuel.
Architecture et intégration
Le produit phare, le Townie, est un assistant IA dédié à chaque employé. Il s’appuie sur des modèles de langage de grande taille hébergés dans le cloud, accessibles via une API interne. Le Townie se connecte aux boîtes mail, aux calendriers et à d’autres systèmes d’entreprise via des connecteurs OAuth standard, ce qui évite la manipulation de mots de passe. Chaque connexion crée un flux de données structuré que le modèle consomme en temps réel pour proposer des réponses contextuelles.
Workflow partagé
Town a introduit un mécanisme de mise à jour automatique du knowledge base des Townies. Au lieu que chaque utilisateur synchronise manuellement son assistant, un service centralisé agrège les nouvelles informations commerciales (ex. changements de prix, nouvelles politiques) et les pousse via un webhook vers tous les agents actifs. Cette architecture repose sur un bus de messages Kafka, garantissant une diffusion en moins de cinq secondes dans la plupart des cas. Le partage d’informations entre Townies autorise également des conversations inter‑agents, tout en respectant des listes blanches d’accès définies par l’administrateur.
Analyse des performances et limites
Le modèle de revenu rapide (ARR en quelques semaines) indique une adoption forte, mais soulève des questions de scalabilité. Le traitement simultané de milliers de requêtes par minute nécessite une orchestration dynamique de conteneurs Kubernetes, ainsi qu’une gestion fine du quota GPU pour éviter la saturation. Le partage d’informations entre assistants implique des risques de fuite de données sensibles si les ACL ne sont pas correctement configurées. De plus, la dépendance à des API tierces (email, calendrier) expose le service à des latences externes et à des restrictions de taux d’appel. Enfin, l’absence de chiffres précis sur le nombre d’utilisateurs rend difficile l’évaluation de la charge réelle supportée par l’infrastructure.
