Les 5 principaux défis du processus de développement de produits d'infrastructure de messagerie

L'infrastructure de messagerie est le système interconnecté qui permet l'envoi, la réception et le stockage de messages électroniques. En tant que tel, il joue un rôle essentiel pour faciliter l'échange d'informations, que ce soit en B2B ou en B2C.

Sur cette note, Radicati Group Inc. estime que le nombre total d'e-mails envoyés atteindra près de 400 milliards en 2027. Et le nombre d'utilisateurs dans le monde devrait atteindre 5 milliards, la même année.

Alors que le volume du trafic de messagerie continue de croître, l'importance d'avoir une infrastructure de messagerie robuste et fiable est difficile à nier.

Cependant, développer et maintenir une infrastructure de messagerie fiable n'est pas sans accroc. Dans cet article, nous discutons des cinq principaux défis auxquels les entreprises sont confrontées dans le processus de développement de produits d'infrastructure de messagerie et proposons des solutions pratiques pour les surmonter.

1 : Évolutivité

Le défi

Étant donné que le trafic ne cesse de croître, l'infrastructure de messagerie peut avoir du mal à gérer la charge. Les entreprises doivent prendre des mesures préventives pour s'adapter à la croissance et éviter les interruptions de service.

Le remue-méninges des mesures en parallèle avec le développement du concept est favorable. Si ce n'est pas le cas, les développeurs doivent le faire avec la sortie de MVP, sinon ils risquent ce qui suit :

• Perte de productivité
• Baisse de la satisfaction des clients
• Pertes financières potentielles
• Baisse des notes d'autorité de domaine
• Baisse de la réputation de l'expéditeur

Les solutions:

• Infrastructure basée sur le cloud
• L'équilibrage de charge

L'utilisation d'une infrastructure basée sur le cloud

Avec une infrastructure basée sur le cloud, les développeurs tirent parti de l'évolutivité et de la fiabilité des services de messagerie tiers. À leur tour, ils sécurisent les ressources nécessaires pour répondre aux besoins croissants des clients.

Cela semble prometteur, mais comment cela fonctionne-t-il réellement ?

Les services de messagerie tiers utilisent de grands centres de données centralisés pour stocker et traiter les données. Ainsi, les sociétés de développement de logiciels peuvent tirer parti des dernières technologies et ressources sans investir dans les leurs. Et cela aide à faire d'une pierre deux coups :

1. L'approche réduit considérablement les coûts opérationnels.
2. Il fournit également aux organisations une solution évolutive pour répondre à leurs besoins croissants.

La chose importante à souligner ici est que vous devez développer une infrastructure basée sur le cloud une étape à la fois. Cela signifie qu'il est préférable de commencer à exécuter certaines tâches dans le cloud, puis de mettre à l'échelle les tâches elles-mêmes en fonction de la charge actuelle (dans ce cas, le volume d'e-mails ou de demandes des utilisateurs).

Mais les tâches basées sur le cloud ne doivent pas être dimensionnées ad hoc, il est crucial de déterminer la stratégie de développement de produit respective. Plus important encore, vous devez savoir s'il y a des défis et des goulots d'étranglement associés à cela.

La mise en place de l'équilibrage de charge

Avant d'approfondir un peu, gardez à l'esprit que l'équilibrage de charge doit être mis en œuvre avec une infrastructure basée sur le cloud. Au mieux, dans une phase de développement de produit.

Désormais, l'équilibrage de charge fait référence à la répartition des charges de travail sur plusieurs architectures et tâches dans le cloud. Le principal avantage est que le produit existant devient capable de gérer un volume accru, même lors des pics de trafic.

Étant donné que les charges de travail sont réparties sur plusieurs serveurs, aucun serveur n'est limité par le volume du trafic de messagerie. Par conséquent, les risques d'interruptions de service et de goulots d'étranglement sont considérablement réduits.

Mieux encore, les algorithmes d'équilibrage de charge peuvent être utilisés pour ajuster dynamiquement la répartition des charges de travail, généralement en fonction de deux facteurs :

1. Le nombre de demandes.
2. La puissance de traitement de chaque serveur.

Construire une sacrée plateforme d'hébergement

En 2012, le processus de développement de produits d'Airbnb était à une étape charnière.

Ils frappaient le public cible directement sur la tête, mettant à l'échelle toute la plate-forme. Mais les commentaires des utilisateurs ont révélé un nombre alarmant de cas extrêmes impliquant des demandes de modification, des litiges et des remboursements. À l'époque, tous ces éléments étaient gérés manuellement par e-mail, sans backend pour prendre en charge le traitement des demandes, ce qui pesait considérablement sur la mise à l'échelle de l'entreprise.

Airbnb était confronté à un choix risqué : embaucher plus de 1 000 personnes en un an ou créer un cadre automatisé pour gérer les cas extrêmes.

Oui, ils ont choisi ce dernier.

Jonathan Golden, chef de produit Airbnb à l'époque, a dû impitoyablement prioriser. L'objectif principal était de créer un plan pour une solution cloud automatisée (framework backend) qui gérerait et catégoriserait les cas extrêmes.

Avec le cadre en place, Airbnb a été débloqué rapidement et a continué à évoluer de 300% à 600% par an. Notez que ces pourcentages se réfèrent à la croissance exponentielle précoce d'Airbnb.

Cependant, il y a plus à retenir de cet exemple pour le développement de produits que de tout déplacer vers le cloud et d'automatiser les flux de travail.

• Il est essentiel de d'abord gérer manuellement un défi technique. Sinon, les développeurs pourraient ne pas être bien conscients des problèmes de racine.
• Une entreprise ne devrait pas attendre trop longtemps avant d'appliquer l'automatisation de la mise à l'échelle, l'équilibrage de charge, etc. Si vous ne le faites pas à temps, les défis risquent de croître tellement qu'il devient beaucoup plus difficile de les surmonter.
• Essayez toujours de créer une solution ou un cadre qui pourrait être appliqué à d'autres problèmes dans la feuille de route du produit. Cela rend vos équipes beaucoup plus agiles.

2 : Sécurité

Le défi

La sécurité de l'infrastructure de messagerie, ou son absence, est essentielle car elle a un impact direct sur la capacité des organisations à communiquer efficacement avec des clients potentiels.

Une équipe de développement de produits doit relever ce défi à un stade précoce, bien avant le produit minimum viable. Mais cela ne s'arrête pas là. Des audits de sécurité réguliers doivent être une priorité même s'il s'agit d'un produit fini.

Comme les informations confidentielles sont souvent échangées par e-mail, une faille de sécurité peut entraîner l'exposition d'informations sensibles. Cela peut avoir de graves conséquences pour les organisations, notamment une atteinte à la réputation, une perte de confiance des clients et des répercussions juridiques potentielles.

En outre, il est important que toutes les équipes comprennent les risques de sécurité potentiels afin d'éviter les violations susceptibles de contourner les protocoles de chiffrement et de sécurité. L'un de ces risques est l'ingénierie sociale, mais plus à ce sujet dans l'une des sections suivantes.

Les solutions:

• Chiffrement
• Protocoles sécurisés
• Mises à jour régulières des mesures de sécurité

Les protocoles sécurisés, tels que SSL et TLS, fournissent des services de cryptage et d'authentification pour les données de messagerie en transit. Pour cette raison, ils peuvent être considérés comme la première ligne de défense dans la feuille de route des produits d'infrastructure de messagerie. En outre, les organisations doivent régulièrement revoir et mettre à jour les mesures de sécurité internes.

Comment?

Par exemple, une entreprise développant le logiciel doit établir des politiques internes pour les ingénieurs et autres parties prenantes afin de limiter l'accès à la base de code, aux gits, etc. En même temps, l'entreprise doit avoir des protocoles clairs sur comment et pourquoi quelqu'un peut se voir accorder plus privilèges d'accès.

Les équipes de développement utilisent généralement le principe de la liste des privilèges pour atteindre un niveau de sécurité plus élevé. Cela signifie que plus d'accès sont accordés à la demande et que très peu de personnes ont accès à tout.

Nous avons précédemment évoqué SSL et TLS qui cryptent les données en mouvement (données en transit). Mais les entreprises doivent également tenir compte du chiffrement des données au repos et établir différents niveaux d'accès à ces données.

"Promis Pinky, nous ne te piraterons pas !"

Il s'agit d'une analyse de rentabilisation quelque peu négative, mais elle montre clairement qu'il y a toujours deux aspects à la sécurité : les logiciels et les personnes.

En janvier 2023, Mailchimp a subi une faille de sécurité (la troisième en 12 mois), exposant les données sensibles de 133 clients. Et l'ingénierie sociale était la stratégie utilisée par les escrocs pour accéder à des informations sensibles.

En gros, cela signifiait que les fraudeurs en ligne utilisaient des employés Mailchimp sans méfiance, et probablement inexpérimentés, pour accéder à des données protégées. Les escrocs ont hameçonné les employés pour obtenir leurs informations d'identification, piratant ainsi les personnes, pas le système lui-même. Néanmoins, les informations sensibles d'environ 133 clients ont été exposées.

L'essentiel est que l'aspect technique de la sécurité doit être à l'épreuve des balles. Mais, en même temps, une entreprise doit établir des procédures et éduquer les employés sur la façon d'éviter de devenir victime d'hameçonnage ou de tout autre type de victime en ligne.

3 : Fiabilité

Le défi

La fiabilité détermine la capacité d'un système à fonctionner correctement et de manière cohérente dans le temps. En tant que tel, c'est l'un des plus grands obstacles lors des différentes itérations d'un nouveau processus de développement de produit.

Pourquoi?

Sans fiabilité, les utilisateurs ne peuvent pas être sûrs que leurs e-mails seront livrés et reçus comme prévu, détruisant finalement la proposition de valeur. Bien sûr, c'est le cas pour l'infrastructure de messagerie, mais il y a une image plus large ici.

La fiabilité du produit final en SaaS impacte directement la réputation de la marque et sa capacité à livrer. Qu'il s'agisse d'un MVP ou d'un produit déjà performant, il doit résister à divers types de pannes, telles qu'une utilisation accrue de la RAM, des pics de demandes des utilisateurs, des charges d'infrastructure inattendues, etc.

La solution:

• Mise en place de systèmes de redondance et de sauvegarde
• Surveillance régulière des infrastructures

La redondance implique d'avoir plusieurs copies des mêmes données stockées à différents endroits. Donc, si un système tombe en panne, il y a une sauvegarde à utiliser. Plusieurs technologies permettent cela, notamment l'équilibrage de charge, où les e-mails sont distribués sur plusieurs serveurs pour réduire le risque d'échec.

Ensuite, la surveillance régulière de l'infrastructure fournit des métriques qui permettent aux développeurs de détecter et de résoudre les problèmes avant qu'ils ne deviennent de véritables problèmes. Cela peut être fait avec des outils de surveillance et des vérifications régulières du système. Ou, parfois, les équipes de développement peuvent appliquer une analyse SWOT lors des tests de concept pour déterminer les meilleures approches.

En parlant de surveillance, il est préférable que les développeurs construisent des alarmes en plus de la surveillance. Par exemple, les alarmes doivent être définies pour les circonstances suivantes :

1. Si les processus commencent à consommer plus de mémoire.
2. S'il y a des problèmes spécifiques de traitement/informatique des données.
3. Dans le cas de 500 réponses de code.

Ces alarmes concernent le support interne de l'architecture et la gestion des produits d'astreinte ; qui doivent tous deux être établis au cours du processus de développement du logiciel ou lors du lancement du produit logiciel.

En clair, lorsqu'une alarme est déclenchée par un événement préoccupant, un ingénieur doit sauter dessus, même si c'est au milieu de la nuit.

Comment les géants l'ont fait

Google lui-même est un excellent exemple d'une stratégie de conception de produits qui a surmonté avec succès les problèmes de fiabilité dès le début. Leur infrastructure est conçue pour présenter plusieurs niveaux de redondance. Cela permet au géant du moteur de recherche de s'assurer que les e-mails des utilisateurs sont livrés et reçus comme prévu, même en cas de défaillance interne.

Un autre exemple est Microsoft, qui a mis en place une infrastructure de messagerie hautement fiable grâce à l'utilisation de systèmes d'équilibrage de charge et de sauvegarde. Ces mesures ont aidé Microsoft à garantir que son service de messagerie reste hautement fiable, même face à une croissance importante et à une demande accrue.

Mais malheureusement, ce n'est plus comme ça. Au cours du cycle de vie du produit, il y a eu quelques points d'inflexion où Microsoft n'a peut-être pas réussi à mener une étude de marché et une analyse des concurrents appropriées - plus à ce sujet dans la section Gestion des attentes en matière de performances .

4 : Interopérabilité

Le défi

L'interopérabilité indique la capacité de l'infrastructure de messagerie, ou de tout service SaaS, à s'intégrer et à bien fonctionner avec d'autres applications.

En règle générale, les intégrations doivent inclure :

1. Gestion de la relation client (CRM)
2. Planification des ressources d'entreprise (ERP)
3. Stockage de données

Quel est l'avantage ?

La possibilité d'échanger des informations de manière transparente entre différentes applications aide les entreprises à prendre des décisions éclairées et basées sur les données. De plus, cela leur permet de rationaliser les processus liés aux produits. Le bonus est qu'une interopérabilité élevée permet également une bien meilleure expérience utilisateur.

Notez simplement que cet aspect doit être abordé lors de la réflexion sur le concept du produit. Et il est avantageux de peser les options d'intégration par rapport à ce qui est disponible sur le marché cible.

La solution:

• Normes ouvertes
• Compatibilité multiplateforme

Les normes ouvertes sont des spécifications accessibles au public qui permettent à différents systèmes de fonctionner ensemble.

Les principales normes ouvertes avec l'infrastructure de messagerie incluent le protocole SMTP (Simple Mail Transfer Protocol), le protocole Post Office version 3 (POP3) et le protocole IMAP (Internet Message Access Protocol).

En ce qui concerne la compatibilité, l'infrastructure de messagerie doit être conçue pour fonctionner avec différents systèmes d'exploitation (Windows, macOS et Linux), ainsi qu'avec différents navigateurs Web (Google Chrome, Mozilla Firefox, Safari, etc.).

Cependant, l'intégration de normes ouvertes et la sécurisation de la compatibilité multiplateforme ne sont pas sans défi. Prenez SMTP par exemple, les développeurs doivent souvent y apporter des ajustements spécifiques, et peut-être même ajouter un cryptage. Pour réaliser facilement ce correctif et d'autres correctifs spécifiques au produit, il est conseillé d'utiliser des plates-formes interconnectées telles qu'AWS.

Enfin, les équipes de développement doivent porter une attention particulière aux signatures, aux solutions anti-spam, aux enregistrements DNS, etc., en ce qui concerne le bon fonctionnement de leur logiciel avec des intégrations tierces.

En un mot, cela revient à suivre les formats et protocoles standard à chaque étape du processus de développement du produit. Ensuite, les ingénieurs peuvent personnaliser les flux de travail back-end et le front-end si nécessaire.

Coupez-nous un peu de Slack

Si vous pensez que Slack a réussi à réinventer notre façon de collaborer, vous ne vous tromperez pas. Mais la question est de savoir comment ils l'ont fait.

Ne tenons pas compte du fait que Slack disposait d'une solution stable lors de la phase de mise sur le marché. Et oublions une stratégie marketing pleine d'esprit qui a réussi à convertir des hordes d'informaticiens frustrés. L'important ici est ce qui se passe après la conversion.

Tout d'abord, la barre pour entrer dans Slack est très basse. Cependant, il couvre la plupart des cas d'utilisation que vous pouvez imaginer. Ensuite, la migration de vos équipes vers Slack est assez simple. La gestion des utilisateurs est simple et la liste des intégrations s'allonge encore et encore…

En fonction de la taille et de la portée de votre entreprise, vous pouvez connecter Jira, Notion, Coda, les applications Google, etc. pour avoir toutes les notifications et tous les canaux de données sous un même toit. Tout cela en quelques jours voire quelques heures.

Ce qui est le plus impressionnant, c'est que l'interopérabilité de Slack est à peu près définie et oubliée. Une fois que vous avez intégré tout ce dont vous avez besoin, vous êtes toujours à un clic d'une source de données ou de communication. Et cette expérience utilisateur est difficile à rivaliser.

5 : Gérer les attentes en matière de performances

Le défi

Le défi de la gestion des attentes en matière de performances consiste à s'assurer que le produit répond aux besoins et aux exigences des utilisateurs finaux. Pour cette raison, il est prudent d'assimiler les attentes en matière de performances aux attentes des utilisateurs, en particulier lors du développement de SaaS.

Pour être clair, le succès d'un produit d'infrastructure de messagerie, ou de tout SaaS, dépend en grande partie de la façon dont les utilisateurs finaux et les clients cibles le perçoivent. C'est-à-dire dans quelle mesure le produit répond aux attentes de performance de l'utilisateur.

Avec la dépendance croissante au courrier électronique, les utilisateurs s'attendent à ce que l'infrastructure soit sécurisée, rapide et fiable. De plus, les utilisateurs veulent que ce soit :

• Facile à utiliser
• Accessible depuis plusieurs appareils
• Être capable de gérer le trafic de messagerie à grande échelle

La solution:

• Essai
• Optimisation
• Communication claire
• Boucles de rétroaction

Au risque d'énoncer une évidence, des tests et une optimisation réguliers doivent faire partie intégrante de tout processus de développement de produit. Cela peut impliquer la réalisation d'enquêtes, de groupes de discussion, de tests A/B pour recueillir les commentaires des utilisateurs, etc.

Une communication claire va de pair avec les tests car elle contribue à renforcer la confiance et la transparence. Souvent, la communication comprend des mises à jour publiques régulières sur le processus de développement, informant les utilisateurs des modifications de l'infrastructure et répondant aux problèmes de performances générés par les utilisateurs.

Toutes les communications et les tests donnent aux développeurs des commentaires qualifiés des clients qui, à leur tour, aident à répondre à leurs besoins et attentes. L'étape critique ici consiste à intégrer les commentaires donnés dans les processus de développement de produits.

Simplement, cela signifie être vigilant à tous les inconvénients d'un système. Peut-être même faire une analyse commerciale pour mieux comprendre quelle méthodologie appliquer pour améliorer le produit sans nuire à sa commercialisation.

Ensuite, l'étape cruciale consiste à transformer tous les résultats en tâches et mises à jour exploitables pour rationaliser davantage votre logiciel.

Mais, lors du test et de la surveillance de votre application, il y a certaines choses à garder à l'esprit. Par exemple, les tests de résistance déterminent si le code s'exécute lentement. Cependant, le fait que quelque chose fonctionne lentement ne nécessite pas de mise à jour. Les équipes de développement ont besoin de bien comprendre quelles mises à jour sont critiques pour les performances et lesquelles peuvent être dépriorisées pour une utilisation optimale des ressources.

La bataille des géants

Comme mentionné précédemment, cette section explore les domaines dans lesquels Microsoft a peut-être échoué dans ses attentes en matière de performances, laissant ainsi la place à ses concurrents de prospérer. Il y a une petite histoire, impliquant à la fois Apple et Google.

Au moment où ils ont publié MPP (Mail Privacy Protection) en septembre 2021, Apple avait déjà battu Google pour la part de marché des clients de messagerie. À l'époque, la part d'Apple était proche de 59 %, celle de Google d'environ 28 %, mais Outlook de Microsoft était loin derrière à environ 5 %.

Maintenant, quelles pourraient être les raisons pour lesquelles Microsoft a été battu à mort ?

Pour trouver la réponse, il faudrait regarder un peu plus loin dans le passé.

Google a lancé Gmail le 1er avril, il y a près de deux décennies. Et il n'a pas fallu longtemps à Microsoft pour se rendre compte que ce n'était pas un poisson d'avril. Le père de Windows a poussé fort pour rester dominant pendant une dizaine d'années. Mais une fois que Gmail a pris le contrôle du marché en 2015, ce fut surtout une spirale descendante pour Outlook.

Mais pourquoi?

Il est prudent d'affirmer que les raisons sont des attentes de performance manquées. Fondamentalement, Gmail était plus rapide et plus facile à utiliser, et il offrait une interface beaucoup plus simplifiée. Couplé à plus de fonctionnalités et à un stockage beaucoup plus important (1 Go - 500 fois plus qu'Outlook à l'époque), il n'est pas surprenant que Gmail ait gagné.

Avance rapide jusqu'à aujourd'hui, et il est clair que Google pourrait être dans le même pétrin que Microsoft il y a dix ans. Maintenant, l'attente de performance clé qui a échoué est le suivi. Compte tenu du nombre d'e-mails entrants, qu'ils soient marketing ou transactionnels, les gens préfèrent garder leurs événements d'e-mail cachés.

Bien sûr, le fait qu'il devient de plus en plus difficile de suivre les taux d'ouverture, les géolocalisations et les appareils donne des brûlures d'estomac aux spécialistes du marketing. Mais les statistiques montrent que c'est exactement ce à quoi les utilisateurs s'attendent.

Les équipes de développement de messagerie d'Apple ont remarqué la tendance très tôt et ont été parmi les premières à proposer une solution viable pour réduire au minimum le bruit des e-mails. Ce type d'attentes de performances, de surveillance et de mises à jour pourrait conduire Apple à dominer l'espace des clients de messagerie dans un avenir prévisible.

Construire de bons produits

À présent, vous devriez avoir une solide compréhension des défis critiques du processus de développement de produits. Pour souligner, peu importe le type de produit que vous développez.

Les défis décrits sont indépendants du créneau et, en grande partie, du cycle de développement de produits. Même si vous n'en êtes qu'au stade de l'idéation, vous souhaitez certainement que le produit soit sûr, fiable et évolutif. Ensuite, lorsque vous atteignez l'étape de démarrage, ne vous arrêtez pas à la sélection et à la validation des idées de produits.

Enfin, il est important de se rappeler que le processus de développement de produits nécessite beaucoup de recherche, d'analyse et de planification de la mise en œuvre à chaque étape du processus. La bonne nouvelle est que cet article vous a donné une feuille de route solide et des domaines clés sur lesquels vous concentrer.