Le cimetière des startups de l’e-mail : pourquoi la plupart des startups de l’e-mail échouent

 (forwardemail.net)
2 points par GN⁺ 2025-08-25 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Matrice d’échec des startups de l’e-mail

  • La plupart des startups de l’e-mail se contentaient d’ajouter une simple interface utilisateur sur une infrastructure existante comme Amazon SES ou Postfix
  • Skiff, Sparrow, Email Copilot, ReplySend, Nveloped, Jumble, InboxFever, etc. ont tous échoué ou ont été arrêtés après leur acquisition
  • La plupart des startups de l’e-mail passées par YC et Techstars ont pivoté ou se sont arrêtées prématurément
  • Les services incapables de construire leur propre infrastructure n’ont survécu qu’à court terme

Vérification de la réalité de l’infrastructure

  • La plupart des startups de l’e-mail ne construisent pas de véritables serveurs et développent seulement des applications ou des clients
  • Les entreprises qui ont réussi proposent une API SMTP et une infrastructure d’acheminement, comme SendGrid, Mailgun, Postmark
  • Le schéma gagnant consiste à renforcer les workflows existants plutôt qu’à tenter de changer le protocole

Pourquoi la plupart des startups de l’e-mail échouent

  • 1. Le protocole fonctionne bien, mais sa mise en œuvre est difficile

    • SMTP, IMAP et POP3 ont fait leurs preuves depuis des décennies
    • Le problème n’est pas un nouveau protocole, mais la qualité de l’implémentation

  • 2. Les effets de réseau sont absolus

    • L’e-mail est utilisé par plus de 4 milliards de personnes et reste compatible avec toutes les plateformes
    • Le coût du remplacement est élevé, ce qui rend le passage à un autre service difficile

  • 3. Elles visent le mauvais problème

    • « L’e-mail est complexe », « il faut de l’IA », « la sécurité est faible » : autant de mauvaises hypothèses
    • Les vrais enjeux sont la fiabilité de la délivrabilité, le filtrage du spam et les outils pour développeurs

  • 4. La dette technique est importante

    • Exploiter un serveur SMTP, gérer le spam, le stockage à grande échelle, l’authentification et l’infrastructure de distribution sont tous difficiles à mettre en place

  • 5. L’infrastructure existe déjà

    • Amazon SES, Postfix, Dovecot, SpamAssassin : l’infrastructure open source et commerciale est déjà abondante

Études de cas d’échec de startups de l’e-mail

  • Le cas Skiff

    • Positionnée comme une « plateforme de productivité et d’e-mail axée sur la confidentialité », l’entreprise a levé d’importants capitaux-risque
    • En février 2024, Notion a acquis Skiff en promettant son intégration et la poursuite du développement
    • En réalité, quelques mois seulement après l’acquisition, le service a été arrêté immédiatement, et les fondateurs ont quitté Notion pour rejoindre Cursor
    • Des milliers d’utilisateurs ont été forcés de migrer

  • Analyse par accélérateur

    • Y Combinator : une usine à applications e-mail

      • Emailio (2014) : client e-mail mobile → pivot vers le bien-être
      • MailTime (2016) : e-mail au format chat → pivot vers un service d’analytics
      • reMail (2009) : recherche d’e-mails sur iPhone → acquis par Google puis arrêté
      • Rapportive (2012) : profils sociaux pour Gmail → acquis par LinkedIn puis arrêté
      • Taux de réussite : quelques acquisitions réussies (reMail, Rapportive), mais la majorité s’est terminée par un pivot ou un acqui-hire

    • Techstars : le cimetière de l’e-mail

      • Email Copilot (2012) : acquis puis arrêté
      • ReplySend (2012) : échec complet
      • Nveloped (2012) : « Easy. Secure. Email » → échec
      • Jumble (2015) : service de chiffrement d’e-mails → échec
      • InboxFever (2011) : API e-mail → échec
      • Schéma : proposition de valeur floue, absence d’innovation technique concrète, échec rapide

  • Le piège du capital-risque

    • VC Funding Paradox : les startups de l’e-mail paraissent simples, mais sont en réalité presque impossibles à faire réussir
    • Les prémisses mêmes qui attirent les investisseurs garantissent l’échec
    • Réalité : l’infrastructure et les protocoles e-mail sont déjà robustes, et il est impossible pour une nouvelle startup de les remplacer

La réalité technique de la stack e-mail moderne

  • La plupart des startups de l’e-mail ne reconstruisent pas une infrastructure complète ; elles ajoutent plutôt une application cliente au-dessus de serveurs et protocoles e-mail existants

  • Cela entraîne la répétition de limites fondamentales et de problèmes de performance, qui constituent l’un des axes de l’échec de ces startups

  • Surconsommation mémoire (Memory Bloat)

    • Les clients e-mail modernes sont principalement conçus comme des webapps basées sur Electron, et consomment excessivement de la RAM
    • Mailspring : 500MB+ de mémoire utilisés pour les fonctions e-mail de base
    • Nylas Mail : 1GB+ de mémoire avant son arrêt
    • Postbox : 300MB+ même au repos
    • Canary Mail : crashs fréquents dus à des problèmes de mémoire
    • Thunderbird : cas signalés d’utilisation allant jusqu’à 90 % de la mémoire système
    • Crise de performance d’Electron :
      • Des frameworks cross-platform comme Electron ou React Native sont pratiques pour les développeurs, mais utilisent les ressources de manière inefficace
      • Résultat : de simples fonctions e-mail peuvent mobiliser de plusieurs centaines de Mo à plusieurs Go de mémoire

  • Décharge de batterie (Battery Drain)

    • En raison d’un code et de modes de fonctionnement inefficaces, la consommation de batterie est sévère sur mobile et sur ordinateur portable.
    • Les processus en arrière-plan restent constamment actifs
    • Des appels API inutiles sont effectués toutes les quelques secondes
    • La gestion des connexions est inefficace
    • Même sans dépendances tierces inutiles au-delà des fonctions essentielles, le gaspillage de ressources reste important

Schémas d’acquisition : succès vs échec

  • Deux schémas

    • Schéma des applications clientes (échec dans la plupart des cas)
      • Les applications clientes e-mail sont généralement arrêtées rapidement après leur acquisition
      • Elles mettent en avant une nouvelle expérience utilisateur, mais restent incapables de surmonter la dépendance à l’infrastructure et la barrière des effets de réseau, ce qui rend leur maintien impossible
    • Schéma de l’infrastructure (souvent gagnant)
      • Les entreprises qui fournissent une infrastructure e-mail essentielle comme SMTP ou des API continuent souvent à croître après leur acquisition, ou sont intégrées à des plateformes avec des résultats durables

  • Cas récents

    • Échecs des applications clientes

      • Mailbox → Dropbox → Shutdown (2013–2015)
      • Sparrow → Google → Shutdown (2012–2013)
      • reMail → Google → Shutdown (2010–2011)
      • Skiff → Notion → Shutdown (2024)

    • Succès exceptionnel

      • Superhuman → Grammarly (2025)
        • Exemple d’acquisition réussie grâce à une intégration stratégique ; un exit réussi rare dans le domaine des clients e-mail

    • Succès de l’infrastructure

      • SendGrid → Twilio (2019) : acquisition à 3 milliards de dollars, suivie d’une croissance continue
      • Mailgun → Sinch (2021) : intégration via une acquisition stratégique
      • Postmark → ActiveCampaign (2022) : a contribué à l’extension des fonctionnalités de la plateforme
  • Les applications clientes finissent souvent par être arrêtées après leur acquisition, tandis que les fournisseurs d’infrastructure ont une nette tendance à survivre et à devenir des éléments clés des plateformes après leur rachat

Évolution et consolidation du secteur

  • Une évolution naturelle du secteur

    • Avec le temps, le secteur de l’e-mail a évolué vers un modèle où les grandes entreprises rachètent de plus petites sociétés pour intégrer leurs fonctionnalités ou éliminer la concurrence
    • Ce n’est pas un phénomène uniquement négatif, mais un processus naturel que l’on observe dans la plupart des secteurs matures

  • Les changements après une acquisition

    Lorsqu’une entreprise de l’e-mail est acquise, les utilisateurs peuvent connaître les changements suivants :
    • Migration du service : nécessité de transférer comptes et données vers une nouvelle plateforme
    • Évolution des fonctionnalités : des fonctions spécialisées peuvent disparaître ou être remplacées autrement
    • Ajustement des prix : le modèle d’abonnement et les tarifs peuvent changer
    • Inconfort pendant l’intégration : des perturbations ou interruptions temporaires peuvent survenir pendant l’intégration du service

  • Ce que les utilisateurs doivent prendre en compte pendant la transition

    Réponses possibles des utilisateurs en période de consolidation du secteur :
    • Évaluer des services alternatifs : rechercher d’autres fournisseurs offrant des fonctionnalités similaires
    • Identifier le parcours de migration : la plupart des services proposent des outils d’export, qu’il faut utiliser
    • Prendre en compte la stabilité à long terme : il est préférable de choisir des fournisseurs fiables, présents depuis longtemps

Vérification de la réalité sur Hacker News

Toutes les startups de l’e-mail reçoivent à répétition les mêmes retours sur Hacker News :

La vague actuelle des startups d’e-mail IA

  • La dernière vague

    En 2024, une nouvelle vague de startups d’« e-mail propulsé par l’IA » est apparue, et une première acquisition majeure a déjà eu lieu :
    • Superhuman : 33 millions de dollars levés au total, acquis en 2025 par Grammarly — une acquisition d’application cliente considérée comme un cas de réussite rare
    • Shortwave : un wrapper basé sur Gmail qui ajoute des fonctionnalités de résumé par IA
    • SaneBox : un filtrage d’e-mails par IA qui fonctionne réellement, mais sans être révolutionnaire

  • Les problèmes persistent

    Même avec l’étiquette « IA », les problèmes fondamentaux de l’e-mail ne sont pas résolus :
    • Résumés par IA : la plupart des e-mails sont déjà courts et concis
    • Réponses intelligentes : Gmail les propose déjà depuis des années
    • Envoi programmé d’e-mails : Outlook le prend en charge nativement
    • Détection des priorités : les clients e-mail existants disposent déjà de systèmes de filtrage efficaces
      Réalité clé : les fonctionnalités IA ne constituent pas une solution de fond, car elles exigent en pratique des investissements d’infrastructure massifs pour résoudre des irritants relativement mineurs

Les cas de réussite réels dans l’e-mail

  • Entreprises d’infrastructure (les réussites)

  • Fournisseurs de services e-mail (les survivants)

    • FastMail : en activité depuis plus de 25 ans, entreprise indépendante et rentable
      • Controverse autour de l’investissement dans JMAP : Fastmail a investi des ressources dans le protocole JMAP, dont l’adoption reste limitée depuis plus de dix ans, tout en refusant le chiffrement PGP demandé par de nombreux utilisateurs. Ce choix stratégique est perçu comme une priorité donnée à l’innovation protocolaire plutôt qu’aux demandes des utilisateurs. La plupart des clients e-mail restent encore dépendants d’IMAP/SMTP
    • ProtonMail : centré sur la confidentialité, avec une croissance durable
    • Zoho Mail : exploitation stable au sein d’une vaste suite de produits business
    • Forward Email (nous) : en activité depuis plus de 7 ans, alliant rentabilité et croissance
    • Cas de réussite en entreprise : Forward Email fournit une solution d’e-mail pour 30 000 anciens élèves de l’université de Cambridge, générant 87 000 dollars d’économies annuelles
    • Schéma : ces acteurs renforcent l’e-mail au lieu de le remplacer.

  • Cas de réussite exceptionnel : Xobni

    Xobni est une startup rare à avoir réussi en améliorant l’environnement e-mail existant.
    • La bonne stratégie :
      • Construire sur l’e-mail existant : intégration à Outlook
      • Résoudre de vrais problèmes : gestion des contacts et recherche dans les e-mails
      • Miser sur l’intégration : fonctionnement adapté aux workflows existants
      • Cibler l’entreprise : viser les entreprises prêtes à payer pour des gains de productivité
    • Résultat : acquis par Yahoo en 2013 pour 60 millions de dollars, avec un retour significatif pour les investisseurs.
    • Parcours ultérieur des fondateurs :
      • Matt Brezina : investisseur angel actif, avec des investissements dans Dropbox, Mailbox, etc.
      • Adam Smith : a continué à créer avec succès des entreprises dans le domaine de la productivité
      • Les deux fondateurs démontrent que « le succès dans l’e-mail vient de l’amélioration, pas du remplacement »

  • Le schéma du succès

    Les points communs des entreprises qui ont réussi dans l’e-mail :
    • 1. Construire de l’infrastructure → SendGrid, Mailgun
    • 2. Renforcer les workflows existants → Xobni, FastMail
    • 3. Se concentrer sur la fiabilité → Amazon SES, Postmark
    • 4. Soutenir les développeurs → fournir des API et des outils, pas des applications pour l’utilisateur final

Existe-t-il des cas où l’e-mail a été réinventé avec succès ?

Cette question touche à l’essence même de l’innovation dans l’e-mail
La réponse courte est la suivante : personne n’a réussi à remplacer l’e-mail, mais certains ont réussi à le “renforcer”.

  • Les innovations qui se sont réellement imposées

    Au cours des 20 dernières années, les innovations qui se sont installées dans l’e-mail ont toutes renforcé l’existant au lieu de remplacer les protocoles en place :

  • Les outils qui complètent l’e-mail au lieu de le remplacer

    • Slack : un outil de chat d’équipe, mais qui envoie toujours des notifications par e-mail
    • Discord : une plateforme centrée sur les communautés, mais dont la gestion des comptes reste basée sur l’e-mail
    • WhatsApp : optimisé pour la messagerie, mais les entreprises continuent d’utiliser l’e-mail
    • Zoom : un outil indispensable pour la visioconférence, mais les invitations aux réunions sont envoyées par e-mail

  • L’expérience HEY

    HEY de Basecamp a été récemment la tentative la plus sérieuse de “réinventer” l’e-mail.
    • Lancement : en 2020, avec une campagne de communication massive
    • Approche : proposition d’un nouveau paradigme de l’e-mail autour du tri, du regroupement et des workflows
    • Réaction : certains ont adoré, mais la majorité a conservé son usage habituel de l’e-mail
    • Réalité : au final, cela n’a fait qu’ajouter une nouvelle interface à un e-mail toujours basé sur SMTP/IMAP
    • Cas concret : le fondateur DHH utilise depuis des années Forward Email sur son domaine personnel dhh.dk. Cela montre que même les innovateurs de l’e-mail s’appuient sur une infrastructure éprouvée.

  • Ce qui fonctionne réellement

    Les innovations les plus efficaces dans l’e-mail sont les suivantes :
    • 1. Une meilleure infrastructure : des serveurs plus rapides, un filtrage antispam amélioré, une meilleure délivrabilité
    • 2. Des interfaces renforcées : l’affichage en conversations de Gmail, l’intégration du calendrier dans Outlook
    • 3. Des outils pour développeurs : des API d’envoi d’e-mails, des webhooks de suivi
    • 4. Des workflows spécialisés : intégration CRM, automatisation marketing, e-mails transactionnels

Conclusion : jusqu’à présent, aucune innovation n’a réussi à remplacer l’e-mail ; toutes ont réussi en améliorant l’e-mail existant

Construire une infrastructure moderne pour les protocoles e-mail existants : notre approche chez Forward Email

Avant d’aborder les cas d’échec, il est important de comprendre ce qui fonctionne réellement dans l’e-mail
Le problème n’est pas l’e-mail en lui-même, mais le fait que de nombreuses entreprises créent des problèmes en essayant de “réparer” un système qui fonctionne déjà très bien

  • Le spectre de l’innovation dans l’e-mail

    L’innovation dans l’e-mail peut globalement être divisée en trois grandes catégories :
    • 1. Renforcement des protocoles : implémenter de manière plus fiable et plus rapide des standards comme SMTP, IMAP et POP3
    • 2. Amélioration des workflows : des outils et fonctionnalités qui rendent l’usage existant de l’e-mail plus efficace
    • 3. Innovation UI/UX : amélioration de l’accessibilité et de l’ergonomie grâce à de nouvelles interfaces

  • Pourquoi nous nous concentrons sur l’infrastructure

    Nous avons choisi de construire une infrastructure e-mail moderne plutôt que de créer une nouvelle application. Voici pourquoi :
    • Des protocoles e-mail éprouvés : SMTP fonctionne de manière fiable depuis 1982
    • Le vrai problème, c’est la qualité de l’implémentation : de nombreux services e-mail utilisent encore des stacks logicielles vieillissantes
    • Ce que veulent les utilisateurs = la fiabilité : non pas de nouvelles fonctionnalités, mais des workflows stables qui ne cassent pas
    • Les besoins des développeurs : fournir de meilleures API et de meilleures interfaces d’administration

  • Ce qui fonctionne réellement dans l’e-mail

    Le schéma gagnant est simple : renforcer les workflows e-mail existants au lieu de les remplacer
    • Construire des serveurs SMTP plus rapides et plus fiables
    • Un meilleur filtrage antispam sans perturber les e-mails légitimes
    • Fournir des API pensées pour les développeurs qui exploitent les protocoles existants
    • Améliorer la délivrabilité grâce à une infrastructure correctement conçue
      Conclusion : l’innovation dans l’e-mail ne consiste pas à le “remplacer”, mais à améliorer le système existant grâce à l’infrastructure

Notre approche : pourquoi Forward Email est différent

  • Ce que nous faisons (What We Do)

    • Construire une véritable infrastructure : développement interne de serveurs SMTP/IMAP à partir de zéro
    • Priorité à la fiabilité : garantie de 99,99 % de disponibilité et gestion correcte des erreurs
    • Renforcer les workflows existants : compatibilité avec tous les clients e-mail et fonctionnement stable
    • Support des développeurs : fournir des API et des outils réellement utilisables
    • Compatibilité totale : conformité complète aux standards SMTP / IMAP / POP3

  • Ce que nous ne faisons pas (What We Don’t Do)

    • Développer un nouveau client e-mail soi-disant “innovant”
    • Tenter de remplacer les protocoles e-mail existants
    • Ajouter des fonctionnalités IA inutiles
    • Faire des promesses fantaisistes sur le fait de “réparer” l’e-mail
      L’essentiel, c’est d’améliorer la fiabilité et la compatibilité sur des protocoles éprouvés, et de se concentrer sur une infrastructure qui fonctionne réellement plutôt que sur une innovation de façade.

Comment nous avons construit une infrastructure e-mail qui fonctionne réellement

  • Notre approche anti-startup (Our Anti-Startup Approach)

    Alors que d’autres entreprises brûlaient des millions de dollars pour tenter de réinventer l’e-mail, nous nous sommes simplement concentrés sur la construction d’une infrastructure fiable :
    • Aucun pivot : plus de 7 ans consacrés exclusivement à l’infrastructure e-mail
    • Aucune stratégie de rachat : objectif d’exploitation à long terme, et non revente rapide
    • Aucune surenchère sur l’innovation : il ne s’agit pas de “réparer” l’e-mail, mais de le faire mieux fonctionner

  • Ce qui nous différencie (What Makes Us Different)

    • Conformité aux normes gouvernementales : conformité Section 889, avec des clients institutionnels comme l’Académie navale des États-Unis
    • Support OpenPGP + OpenWKD : prise en charge du chiffrement PGP refusé par Fastmail, avec de véritables fonctions de chiffrement que les utilisateurs veulent
    • Différenciation de la stack technique :
      • l’ensemble de la stack est développé en JavaScript (contrairement à Postfix, basé sur du code C des années 1980)
      • pas besoin de glue code grâce à un langage unique
      • architecture native au Web, très maintenable
      • aucune dette legacy, base de code moderne
    • Privacy by Design :
      • les e-mails ne sont pas stockés sur disque ni en base de données
      • aucun stockage des métadonnées, logs ou adresses IP
      • traitement uniquement en mémoire lors du transfert
    • Les détails d’implémentation de la sécurité et de l’architecture sont publiés via le livre blanc technique et la documentation

  • Pourquoi nous réussissons là où d’autres échouent (Why We Succeed Where Others Fail)

    • 1. Nous construisons de l’infrastructure, pas une app : focus sur les serveurs et les protocoles
    • 2. Nous renforçons au lieu de remplacer : compatibilité maintenue avec les clients e-mail existants
    • 3. Nous sommes rentables par nous-mêmes : une exploitation durable sans pression du capital-risque
    • 4. Compréhension technique approfondie : plus de 7 ans d’expérience spécialisée dans l’e-mail
    • 5. Orienté développeurs : des API et outils qui aident à résoudre de vrais problèmes

Les défis de sécurité de l’infrastructure e-mail

La sécurité de l’e-mail est un défi complexe auquel tous les fournisseurs de services sont confrontés.
Il est important de comprendre les considérations de sécurité communes à traiter, au-delà des incidents individuels.

  • Considérations de sécurité communes (Common Security Considerations)

    • Protection des données : protéger de manière sûre les données utilisateur et les communications
    • Contrôle d’accès : authentification et gestion des autorisations
    • Sécurité de l’infrastructure : protection des serveurs et des bases de données
    • Conformité réglementaire : respect de réglementations comme le GDPR et le CCPA
    • Mise en œuvre de chiffrement avancé : politique de sécurité de Forward Email dans sa politique de sécurité :
      • chiffrement des boîtes mail basé sur ChaCha20-Poly1305
      • chiffrement complet du disque basé sur LUKS v2
      • chiffrement appliqué au stockage, à la mémoire et au transport

  • La valeur de la transparence (The Value of Transparency)

    En cas d’incident de sécurité, la réponse la plus importante est la transparence et l’action rapide. Les bonnes pratiques incluent :
    • divulgation immédiate : permettre aux utilisateurs de comprendre la situation et de réagir
    • fournir une chronologie détaillée : montrer l’ampleur du problème et le niveau de compréhension
    • mesures correctives rapides : démontrer les capacités techniques
    • partage des enseignements : contribuer à l’amélioration de la sécurité dans tout le secteur

  • Défis de sécurité continus (Ongoing Security Challenges)

    La sécurité de l’e-mail continue d’évoluer, et des améliorations permanentes sont nécessaires dans des domaines comme :
    • standards de chiffrement : adoption de méthodes modernes comme TLS 1.3
    • protocoles d’authentification : renforcement de DKIM, SPF et DMARC
    • détection des menaces : amélioration du filtrage du spam et du phishing
    • renforcement de l’infrastructure : amélioration de la sécurité des serveurs et des bases de données
    • gestion de la réputation des domaines : mise en place de règles de blocage pour répondre à de nouvelles menaces, comme la hausse du spam provenant d’adresses Microsoft onmicrosoft.com

Conclusion : concentrez-vous sur l’infrastructure, pas sur les apps

  • Les preuves sont claires (The Evidence Is Clear)

    Après analyse de centaines de startups de l’e-mail :
    • Taux d’échec de 80 % ou plus : la plupart des startups de l’e-mail échouent complètement (le chiffre réel est probablement encore plus élevé)
    • Les apps clientes échouent majoritairement : une acquisition mène généralement à l’arrêt du service
    • L’infrastructure peut réussir : les entreprises qui construisent des services SMTP/API prospèrent souvent
    • La pression du financement VC : le capital-risque crée une pression de croissance irréaliste
    • Accumulation de dette technique : construire une infrastructure e-mail est bien plus difficile que prévu

  • Contexte historique (The Historical Context)

    Depuis 20 ans, les startups prédisent sans cesse la fin de l’e-mail :
    • 2004 : « les réseaux sociaux remplaceront l’e-mail »
    • 2008 : « la messagerie mobile tuera l’e-mail »
    • 2012 : « Slack remplacera l’e-mail »
    • 2016 : « l’IA va révolutionner l’e-mail »
    • 2020 : « l’ère du travail à distance a besoin de nouveaux outils de communication »
    • 2024 : « l’IA va enfin réparer l’e-mail »
      Pourtant, l’e-mail est toujours là, il continue de croître et reste indispensable.

  • La vraie leçon (The Real Lesson)

    La leçon n’est pas qu’on ne peut pas améliorer l’e-mail, mais qu’il faut adopter la bonne approche :
    • 1. Les protocoles e-mail restent valides : SMTP, IMAP et POP3 sont des standards éprouvés
    • 2. L’infrastructure est centrale : la fiabilité et la performance comptent plus que les fonctionnalités tape-à-l’œil
    • 3. Renforcer plutôt que remplacer : ne combattez pas l’e-mail, proposez des améliorations qui fonctionnent avec lui
    • 4. La durabilité plutôt que la croissance : une entreprise rentable survit plus longtemps que le modèle VC consistant à « croître vite et tout casser »
    • 5. Soutenir les développeurs : les outils et API pour développeurs créent plus de valeur que les apps destinées aux utilisateurs finaux
    • Opportunité clé : mieux implémenter des protocoles déjà éprouvés, et non en créer de nouveaux
    • Analyse plus approfondie : 79 Best Email Services (2025)
  • Si vous voulez créer une startup de l’e-mail, envisagez de construire de l’infrastructure plutôt qu’une app.
    • Ce dont le monde a besoin, ce n’est pas de plus d’apps e-mail, mais de meilleurs serveurs e-mail.

Le cimetière étendu de l’e-mail : encore plus d’échecs et de fermetures

  • Les expériences e-mail ratées de Google (Google's Email Experiments Gone Wrong)

    Bien que Google possède Gmail, l’entreprise a tout de même abandonné plusieurs projets liés à l’e-mail :
    • Google Wave (2009–2012) : présenté comme un « tueur d’e-mail », mais personne ne comprenait vraiment le produit
    • Google Buzz (2010–2011) : tentative ratée d’intégration entre social et e-mail
    • Inbox by Gmail (2014–2019) : lancé comme le successeur « intelligent » de Gmail, avant d’être finalement abandonné
    • Google+ (2011–2019) : a tenté d’intégrer des fonctions d’e-mail, sans succès
    • Schéma : même Google, avec Gmail, n’a pas réussi à réinventer l’e-mail

  • Newton Mail et ses trois morts (The Serial Failure: Newton Mail's Three Deaths)

    Newton Mail est littéralement mort trois fois :
    • 1. CloudMagic (2013–2016) : client e-mail initial, ensuite racheté par Newton
    • 2. Newton Mail (2016–2018) : relancement de la marque, puis arrêt après l’échec du modèle par abonnement
    • 3. Newton Mail Revival (2019–2020) : tentative de résurrection, à nouveau échouée
    • Leçon : les clients e-mail ne peuvent pas soutenir durablement un modèle par abonnement

  • Les apps qui n’ont même jamais été lancées (The Apps That Never Launched)

    De nombreuses startups de l’e-mail disparaissent avant même le lancement :
    • Tempo (2014) : tentative d’intégration calendrier-e-mail, arrêtée avant lancement
    • Mailstrom (2011) : outil de gestion des e-mails, acquis avant lancement
    • Fluent (2013) : client e-mail dont le développement a été abandonné

  • Le schéma acquisition puis fermeture (The Acquisition-to-Shutdown Pattern)

    Plusieurs apps e-mail sont arrêtées peu après leur acquisition :

  • Consolidation de l’infrastructure e-mail (Email Infrastructure Consolidation)

    Même du côté de l’infrastructure, les consolidations et fermetures sont fréquentes :

Le cimetière open source de l’e-mail : quand le « gratuit » devient intenable

  • Nylas Mail → Mailspring : un fork en échec

  • Eudora : une marche vers la mort sur 18 ans

    • 1988–2006 : a régné comme client e-mail dominant sur Mac et Windows
    • 2006 : Qualcomm annonce l’arrêt du développement
    • 2007 : passage en open source sous le nom « Eudora OSE »
    • 2010 : arrêt complet du projet
    • Leçon : même les clients e-mail à succès finissent par disparaître

  • FairEmail : mort à cause des politiques de Google Play

    • FairEmail : client e-mail Android centré sur la protection de la vie privée
    • Google Play : supprimé pour « violation des règles »
    • Réalité : les apps e-mail peuvent disparaître du jour au lendemain à cause des politiques des plateformes

  • Le problème de la maintenance (The Maintenance Problem)

    Les raisons de l’échec des projets e-mail open source :
    • Complexité : difficile d’implémenter correctement les protocoles e-mail
    • Sécurité : besoin constant de mises à jour de sécurité
    • Compatibilité : ils doivent être compatibles avec tous les fournisseurs d’e-mail
    • Manque de ressources : épuisement des développeurs bénévoles (burnout)

Boom des startups d’e-mail IA : l’histoire qui se répète sous le nom d’« intelligence »

  • La ruée vers l’or actuelle de l’e-mail IA (2024)

    • Superhuman : 33 M$ levés, acquise par Grammarly en 2025
    • Shortwave : issue de Y Combinator, Gmail + fonction de résumé par IA
    • SaneBox : filtrage d’e-mails par IA, service réellement rentable
    • Boomerang : planification et réponses automatiques basées sur l’IA
    • Mail-0/Zero : développement en cours d’une autre interface de client e-mail IA
    • Inbox Zero : assistant e-mail IA open source, tentative d’automatisation de la gestion des e-mails

  • Frénésie de financement

    • Rien qu’en 2024, les VC ont investi plus de 100 M$
    • Promesse répétée : « expérience e-mail révolutionnaire »
    • Problème récurrent : construction uniquement au-dessus de l’infrastructure existante
    • Résultat récurrent : la plupart devraient échouer en moins de 3 ans

  • Pourquoi cela échouera encore

    • 1. L’IA tente de résoudre un “non-problème” de l’e-mail – l’e-mail fonctionne déjà bien
    • 2. Gmail propose déjà des fonctions IA – réponses intelligentes, boîte de réception prioritaire, filtrage du spam
    • 3. Préoccupations liées à la vie privée – l’IA doit lire tous les e-mails
    • 4. Problème de structure de coûts – le coût du traitement IA est élevé, alors que l’e-mail est fondamentalement un service à faible marge
    • 5. Effets de réseau – impossible de renverser la position dominante de Gmail/Outlook

  • Résultat inévitable

    • 2025 : Superhuman → acquisition par Grammarly (rare cas de réussite)
    • 2025–2026 : la plupart des startups d’e-mail IA pivotent ou ferment
    • 2027 : certaines survivantes sont acquises, avec des résultats mitigés
    • 2028 : apparition probable d’une nouvelle mode comme le « blockchain e-mail »

La catastrophe de la consolidation : quand les « survivants » deviennent le désastre

  • Consolidation à grande échelle des services d’e-mail

    Le secteur de l’e-mail s’est rapidement consolidé

  • Outlook : un « survivant » aux problèmes sans fin

    Microsoft Outlook reste dominant dans le secteur, mais continue de connaître des problèmes
    • Fuites de mémoire : plusieurs Go de RAM utilisés, redémarrages fréquents nécessaires
    • Problèmes de synchronisation : des e-mails disparaissent puis réapparaissent
    • Problèmes de performance : démarrage lent, plantages fréquents
    • Problèmes de compatibilité : conflits avec des fournisseurs d’e-mail tiers

    Cas réel sur le terrain : même en suivant l’implémentation IMAP standard, Outlook se casse souvent

  • Problèmes d’infrastructure chez Postmark

    Problèmes survenus après l’acquisition par ActiveCampaign

  • Cas récents de mort de clients e-mail (2024–2025)

    • Postbox → eM Client : arrêt immédiat juste après l’acquisition, migration forcée des utilisateurs
    • Canary Mail : malgré le soutien de Sequoia, déferlement de plaintes d’utilisateurs
    • Spark by Readdle : augmentation des signalements de baisse de qualité
    • Mailbird : problèmes de licence et confusion autour des abonnements
    • Airmail : code basé sur Sparrow, problèmes de fiabilité persistants

  • Cas d’extensions/services e-mail arrêtés

  • Les entreprises d’e-mail qui ont réellement survécu

    • Mailmodo : issue de YC, campagnes e-mail interactives, 2 M$ levés via Sequoia Surge
    • Mixmax : 13,3 M$ levés au total, toujours en activité comme plateforme d’engagement commercial
    • Outreach.io : valorisation de plus de 4,4 Md$, préparation d’une IPO
    • Apollo.io : valorisée à 1,6 Md$ en 2023, série D de 100 M$
    • GMass : basé sur une extension Gmail, cas de réussite bootstrap avec 140 k$ par mois
    • Streak CRM : CRM basé sur Gmail, exploité de manière stable depuis 2012
    • ToutApp : acquisition réussie par Marketo en 2017
    • Bananatag : acquise par Staffbase en 2021, toujours exploitée sous le nom de « Staffbase Email »

  • Schéma clé

    • Les entreprises qui réussissent ne remplacent pas l’e-mail, elles améliorent le workflow
    • Elles ont créé des outils fonctionnant de manière coopérative avec l’infrastructure e-mail existante

Conclusion

  • Plus de 80 % des startups de l’e-mail échouent
  • L’approche centrée sur l’application échoue, l’approche centrée sur l’infrastructure réussit
  • Enseignements clés :
    • 1. Les protocoles e-mail fonctionnent déjà bien
    • 2. La stabilité et les performances de l’infrastructure sont essentielles
    • 3. Renforcer plutôt que remplacer est plus efficace
    • 4. Un modèle économique durable est nécessaire
    • 5. Les outils et API pour les développeurs sont la clé du succès

À lire aussi

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.