Après 30 ans dans le domaine du développement web, Romain Demoustier “Directeur du conseil” accompagne les clients de premaccess dans la transformation de leur univers informatique. Pour ce manager de transition, les dirigeants ne doivent plus considérer la création de logiciel ou d’application comme un coût fixe, mais comme une charge récurrente, lissée dans le temps. Car, prendre en compte le besoin de ces clients demande désormais d’améliorer son offre en continu. Une posture nouvelle qui favorise le développement de nouvelles stratégies. 


Le developpement Avant Internet et le cloud

« Quand j’ai débuté ma carrière dans l’informatique, nous étions loin du développement itératif : les entreprises pensaient leur logiciel comme un produit à réaliser à un instant T. Il représentait un coût fixe pour leurs dirigeants, explique Romain Demoustier. Cette méthode leur convenait bien, car les logiciels étaient des produits que nous installions sur des postes informatiques. Le coût de distribution des logiciels étaient lourds : envoyer un CD, installer une nouvelle version sur beaucoup de machines prenaient beaucoup de temps. »

À cette époque, les projets de développement étaient menés en suivant notamment la méthode en cascade :

quels sont nos besoins > voici le produit que nous pouvons développer pour y répondre > voici le planning et le coût de ce produit. 

Cette méthode a un inconvénient majeur : entre le moment où vous énonciez vos besoins et la réalisation du produit par les développeurs, un temps s’était écoulé et votre demande avait évolué. Du coup, le produit final ne répondait plus à la requête initiale. Il fallait donc l’étoffer. Résultat : cela vous coûtait plus cher que prévu. 


Depuis, la donne a changé pour les développeurs…

Internet et le cloud ont considérablement bouleversé le métier de développeurs. Aujourd’hui, nous ne parlons plus de logiciels mais d’applications disponibles à la demande (SaaS).

Avec cette transformation digitale, les développeurs ont basculé dans le développement continu. Cela est tangible dans leurs méthodes de travail, plus agiles, plus proches du besoin utilisateur. Les logiciels ne sont plus installés sur des machines, mais sont disponibles sur le cloud. Cela leur permet de les modifier constamment pour mieux répondre à la demande du consommateur. 


… mais aussi pour les dirigeants 

Ce développement continu a forcément un impact sur les finances des entreprises. 

« Je suis souvent consulté par des chefs d’entreprises ou des porteurs de projets pour le développement d’application, rapporte Romain Demoustier. Ils me posent généralement la même question : « Je souhaite développer un nouveau service. J’ai besoin d’une application. Voici les fonctionnalités à créer. À votre avis, combien cela pourrait-il coûter ? Une entreprise m’a fait un devis de 60 000 euros pour développer mon application, qu’en pensez-vous ? »

À chaque fois, ma réponse est identique : il ne faut plus voir une application comme un produit que l’on réalise en une seule fois, mais comme un process continu d’amélioration. Nos méthodes de développement en cascade nous ont prouvé que produire un logiciel en « one-shot » peut coûter plus cher que prévu. Pour rendre nos investissements plus rentables, répartissons-les dans le temps. »

Comme les développeurs qui pensent leur logiciel de façon continue, les dirigeants et porteurs de projets doivent désormais changer leur regard sur la manière de mettre en oeuvre leurs applications. Ils ne doivent plus penser leur logiciel / application comme un coût fixe, mais comme une dépense mensuelle sur la durée du projet. Ainsi, ils pourront l’étoffer au fur et à mesure en fonction des besoins de leurs cibles. Tous doivent avoir en tête qu’une application n’est plus un produit figé, mais un service « vivant » façonné par l’expérience client.

Beaucoup diront que le principal frein à cette méthode est l’estimation du coût sur le long terme. Effectivement, au début, il est difficile de chiffrer complètement le projet. Mais ce projet lui-même n’est pas totalement défini au départ, il va évoluer au fur et à mesure de sa réalisation. L’expérience nous a prouvé que produire ainsi permet de mieux répartir les dépenses lors d’un développement. 


Notre accompagnement chez premaccess

Chez premaccess, nous avons adopté le développement continu avec plusieurs de nos clients. Quand l’un d’entre eux nous sollicite pour le développement d’un logiciel, notre objectif est de définir les besoins initiaux. 

Ainsi, nous développons un PoC (proof of concept). Ce produit n’est pas destiné à entrer en production. Il sert juste à vérifier que tout fonctionne d’un point de vue technique, mais aussi business. 

Une fois validé, nous créons un prototype opérationnel, un MVP (minimum viable product). Nous le mettons en ligne et nous le faisons évoluer progressivement avec le client. 

  • L’intérêt majeur de cette méthode est que le développement d’un MVP coûte bien moins cher.
  • Son second intérêt est que nous le mettons à disposition des utilisateurs de nos clients. Ainsi, nous confrontons l’idée au marché pour l’améliorer progressivement. 

Développement continu : les avantages pour les entreprises

  1. Vous réduisez vos risques d’échecs : De manière générale, les dirigeants ont du mal à conceptualiser ce qu’ils veulent. Lors de projets menés via la méthode en cascade, ces derniers sont très souvent déçus, car le produit final n’est pas celui attendu. La déception est d’autant plus grande qu’il faut réinvestir de l’argent pour modifier à nouveau le produit. En développant en continu, en créant un MVP, et donc en payant au fur et à mesure, cela leur permet de visualiser le résultat et de l’affiner. Vous réduisez ainsi vos risques d’échec car vous testez votre offre auprès de vos clients et vous vous assurez d’aller dans la bonne voie technologique.

  2. Vous dépensez moins au lancement du projet : Produire un MVP vous coûte bien moins cher que de créer un produit « one-shot ». Pourquoi ? Car, vous créez vos fonctionnalités au fur et mesure au lieu de créer un produit avec une multitudes de fonctionnalités qui, une fois sur deux, ne seront pas utilisées par vos utilisateurs. De plus, cela a la mérite de forcer le dirigeant à synthétiser son offre, à définir quelle est sa vraie valeur ajoutée.

  3. Vous gagnerez du temps car, dans cette démarche, il est plus rapide de produire un MVP que de développer en une seule fois un important logiciel avec pléthores de fonctionnalités.

  4. Vous testez et ajustez votre offre auprès de vos utilisateurs. Vous êtes donc plus en alerte de nouveaux business models.

  5. Vous avez un aperçu de vos dépenses : Enfin, l’équipe de premaccess conseillent à ses clients de déployer leur offre sur AWS, car ce cloud provider permet de créer des applications facilement en microservices (serverless). Par ailleurs, il permet d’avoir un aperçu sur vos dépenses : vous payez uniquement les ressources que vous consommez. Ce qui peut s’avérer stratégique en début de projet. Il n’y a plus d’infrastructure complexe à payer même si elle ne sert pas.

Avec le cloud, nous avons basculé dans une économie de plateforme. Nous sommes passés de l’acquisition de produit (payé en une fois) à l’achat mensuel de services (Spotify, Suite Adobe, Office 365…). Cette logique est désormais de mise lors du développement de vos logiciels ou d’applications. Les entreprises doivent l’avoir en tête. D’autant que l’analyse des données vous permet d’étudier la satisfaction de vos utilisateurs afin d’ajuster votre offre très rapidement.

Si vous souhaitez en savoir plus sur ce sujet, n’hésitez pas à contacter l’équipe de premaccess. Elle vous accompagnera pas à pas dans la création de votre projet, et vous présentera les atouts du développement continu.

Le 18 novembre dernier, AWS a annoncé la sortie de son AWS CloudFormation Registry et CLI, une extension d’AWS CloudFormation prenant en charge la création de ressources tierces via la console AWS CloudFormation. C’est également la première fois que le service AWS est associé à des partenaires de lancement tels que Spotinst et Fortinet.


Maintenant, grâce à la prise en charge de ces ressources tierces, AWS améliore toute la pratique de la création d’infrastructure dans le cloud, car le provisionnement s’étend désormais au-delà des ressources AWS pour inclure également des outils SaaS en provenance d’autres fournisseurs, renforçant la façon dont nous construisons dans le cloud.

Par conséquent, le but de cet article est de montrer l’importance d’IaC ‘Infrastructure as Code’ dans le domaine du cloud computing et de souligner l’importance des développements d’AWS pour son service AWS CloudFormation.


Les principes de l’IaC

IaC, abréviation de Infrastructure as Code, est la pratique selon laquelle les ressources sont décrites  par des scripts par opposition à l’utilisation de consoles de gestion qui permettent de créer manuellement des environnements de ressources.
Par conséquent, dans le cas d’AWS CloudFormation, vous n’avez pas besoin d’utiliser la console AWS ou de SDK pour créer des ressources AWS.
De plus, avec AWS CloudFormation Registry, vous avez plus besoin d’utiliser la console d’outils tiers pour utiliser leurs ressources.

Ces scripts lisibles permettent le déploiement automatique des ressources ainsi que les services requis qui vont avec. En effet, les outils IaC vont créer toutes les ressources nécessaire comme par exemple : les réseaux, les machines virtuelles, les équilibreurs de charge et les différents accès pour vos applications.


De plus, chaque fois qu’un script IaC est appliqué, il en résulte toujours le même environnement que celui décrit dans le script.

Par conséquent, les avantages deviennent évidents. L’IaC est une pratique courante pour les DevOps car l’objectif du DevOps est de réaliser l’automatisation du processus de production. En effet, avec l’IaC, nous sommes en mesure d’automatiser la construction de l’infrastructure, ce qui est encore plus crucial dans les environnements cloud.


Même si les environnements cloud soustraient une grande partie de l’architecture sous-jacente aux développeurs, ils nécessitent des configurations fastidieuses des ressources dépendante des contraintes du cloud provider choisi.
Par conséquent, les services IaC tels qu’AWS Cloudformation fournissent une certaine forme de répit face au besoin de configurations répétitives.

D’autres avantages incluent l’indépendance entre les états et les modèles.
Étant donné que l’IaC nous permet de modéliser notre infrastructure dans un format basé sur un script, nous pouvons définir l’état souhaité de notre infrastructure cloud.
Par conséquent, si l’infrastructure s’écarte trop de l’état souhaité, nous pouvons automatiser sa récupération à l’aide du modèle initialement utilisé.

De même, nous pouvons utiliser le même modèle pour répliquer l’état souhaité dans plusieurs environnements (Production/Pré-Production/Recette par exemple). Ceci est extrêmement avantageux à des fins de test, car cela permet  d’avoir des scénarios réels. Ainsi, au lieu d’avoir à configurer ardûment chaque composant pour refléter l’infrastructure à tester, nous pouvons simplement automatiser le provisionnement d’une infrastructure identique, suivi de tests automatisés facilités par les différents outils de CI / CD mis à disposition par le Cloud Provider.

Par conséquent, les outils IaC peuvent être considérés comme des livres  de recettes pour notre infrastructure cloud.
En fait, l’utilisation de cette analogie de livre de recettes pour les services IaC est si courante que Jeff Barr – Chief Evangelist d’AWS a habilement intitulé son blog d’introduction d’AWS CloudFormation https://aws.amazon.com/blogs/aws/cloudformation-create-your-aws-stack-from-a-recipe/, en 2011.

Cependant, les gens ne réalisent pas que les outils IaC ne sont pas comme vos livres de recettes ordinaires, mais plutôt comme des cuisines entièrement automatisées qui analysent ces recettes et cuisinent des infrastructures cloud complètes pour vous.

Nous pouvons convenir que l’IaC, en général, est impératif pour une expérience DevOps complète. La question est maintenant de savoir quels services le plus grand fournisseur de cloud, AWS, fournit en termes d’IaC ?
Avant, la réponse était CloudFormation et son générateur CDK (AWS Cloud Development Kit).


CloudFormation et ses avantages avec CloudFormation Registry

AWS CloudFormation fournit un langage commun pour vous permettre de décrire et de provisionner toutes les ressources d’infrastructure dans votre environnement cloud.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/registry.html

CloudFormation vous permet de définir les ressources AWS souhaitées ainsi que leurs configurations et connexions dans des documents de plan directeurs appelés modèles CloudFormation. Ces modèles sont ensuite exécutés dans la console AWS CloudFormation pour provisionner l’infrastructure définie.
Ce faisant, le service garantit que les composants de l’infrastructure cloud sont déployés de la bonne manière en fonction des dépendances décrites dans le modèle CloudFormation.

Par exemple, si vous souhaitez qu’une instance EC2 s’exécute dans un VPC, CloudFormation garantit que le VPC est d’abord provisionné, puis l’instance EC2.
Cela signifie également que nous n’avons plus besoin d’utiliser la gestion AWS pour configurer et ajouter manuellement l’instance EC2 dans le VPC.

Cependant, un domaine que AWS CloudFormation n’avait pas était le provisionnement des ressources tierces. Oui, les ressources AWS constituent le cœur de l’infrastructure de l’application, mais ces composants communique très probablement avec des outils SaaS tiers quelque part dans le flux de travail de vos applications.
Pour revenir à l’exemple d’une instance EC2 dans un VPC, nous pouvons avoir besoin de cette instance EC2 pour ensuite interagir avec l’API Stripe.

Par conséquent, même si nous avons réussi à automatiser avec vos DevOps du côté AWS, nous ne disposions toujours pas d’outils lorsqu’il s’agissait de connecter nos infrastructures tiers à l’infrastructure AWS principale.
Cela nous ramènerait souvent à la case départ car les avantages de l’IaC discutés ci-dessus étaient limités aux seules ressources AWS.

C’est là qu’intervient AWS Cloud Registry !

Désormais, avec la nouvelle version, la capacités d’AWS CloudFormation a ce connecter sur les ressources externes est résolu. Le registre AWS CloudFormation permet le provisionnement de ces outils tiers externes avec les ressources AWS.

Avec la sortie de ce nouveau service, il y a un total de sept outils SaaS offrant leurs ressources sur le registre.
Par exemple, avec la prise en charge d’Atlassian Opsgenie par le registre AWS CloudFormation, vous pouvez désormais provisionner des ressources Opsgenie telles que des utilisateurs, des équipes et des intégrations avec vos ressources AWS.
Vous pouvez donc automatiser la configuration des services de gestion des incidents Opsgenie dans votre infrastructure AWS.

Cela signifie que nous pouvons désormais bénéficier davantage des pratiques DevOps, car AWS a étendu ses services IaC sur des piles de technologies externes et ne se limite pas uniquement à AWS.
De plus, AWS CloudFormation Registry est open source, de sorte que la communauté peut constamment créer plus de ressources personnalisées qui peuvent être provisionnées automatiquement via l’AWS CloudFormation CLI. Cela améliore l’adoption du cloud, en particulier en utilisant le IaC pour déployer vos architectures AWS.


Un pas de plus avec AWS CloudFormation CLI

AWS CloudFormation fournit des ressources tierces à inclure dans les livres de recettes de vos infrastructures cloud souhaitées.


Si nous devons suivre cette analogie de recette, le registre CloudFormation peut être considéré comme votre garde-manger de ressources, où votre garde-manger stocke les ressources fournies par les partenaires SaaS tiers.

La question est alors de savoir si vous souhaitez étendre ce garde-manger?

C’est là que le composant CLI entre dans la nouvelle version d’AWS CloudFormation. L’AWS CloudFormation CLI nous fournit un ensemble d’ustensiles qui nous permet de créer nos propres ressources personnalisées que nous pourrons ensuite inclure dans les modèles AWS CloudFormation, ce qui nous donne la liberté d’étendre nos garde-manger à l’infini.

AWS fournit la CFN ( CloudFormation Command Line Interface ) qui nous permet d’initialiser nos projets de ressources personnalisés, et génère automatiquement la structure de code de base pour nous et ensuite nous permet de tester nos ressources construites tout en l’enregistrant dans nos registres AWS CloudFormation privé .

AWS nous fournit un ensemble complet de ressources pour commencer à créer ces nouvelles ressources. De plus, la poussée de l’open source avec AWS CloudFormation open source signifie que nous pouvons nous attendre à ce que beaucoup de bibliothèque de ressources soit disponible et facile à inclus dans nos modèles AWS CloudFormation.

Améliorant ainsi toute l’expérience d’utilisation du service IaC, augmentant la vitesse avec laquelle nous construisons dans le cloud.


Récapitulatif de ce que AWS CloudFormation signifie pour le DevOps

Avec le registre AWS CloudFormation et l’interface CLI, nous voyons les avantages d’avoir des ressources tierces non AWS dans nos processus d’infrastructure cloud.

Nous pouvons être assurés que l’utilisation d’AWS CloudFormation pour des applications et la gestion des infrastructures cloud couvre désormais l’intégralité de votre besoins et pas seulement des ressources AWS spécifiques.

La flexibilité de l’AWS CloudFormation CLI et la fiabilité de l’expansion du registre AWS CloudFormation ne peuvent que signifier qu’avec le temps, comme de plus en plus de ressources seront disponibles, nous pouvons nous attendre à ce que le développement dans le cloud deviennent beaucoup plus facile. Nous ne devons plus réinventer la roue, il nous suffit maintenant de nous soucier de la destination.

Bonne lecture ! Contactez-nous si vous avez des besoins en Développement ou en Service Managés Cloud.

Qui n’a pas connu cette frustration de devoir renvoyer un vêtement ou une paire de chaussures, aussitôt reçus par La Poste, suite à une erreur de taille ? Pour éviter ces imprévus lors des commandes en ligne, la start-up Fitizzy a mis au point un algorithme particulièrement intelligent. Il recommande à l’internaute la taille qui lui convient le mieux en fonction de ses mensurations et des patronages de différentes marques. 

Dédié initialement au prêt-à-porter grand public, partenaire de grandes marques comme Promod, Naf Naf, Celio, Cyrillus ou bien Etam pour la lingerie, Fitizzy s’ouvre depuis deux ans au secteur professionnel.

L’apparition de cette offre B2B a été possible suite à la bascule des applications de Fitizzy dans le cloud AWS et à l’utilisation des microservices proposés par ce cloud provider. Lors de cette étape stratégique, la start-up a été soutenue par l’équipe de premaccess techniquement, mais également en termes de business. Christophe Del Fabbro, CTO de Fitizzy, a participé pleinement à cette migration.

Dans cette interview, il revient sur la genèse de Fitizzy, et sur l’offre proposée. Il nous explique également comment l’application a été déployée sur AWS afin d’accélérer le développement de cette entreprise innovante.

Avec Fitizzy, les leaders du prêt-à-porter réduisent leurs taux de retour

« Fitizzy est née en 2013 grâce à Sébastien Ramel et Gaultier Monier. Lorsqu’ils étaient étudiants, tous deux avaient toujours peur d’acheter des vêtements en ligne, car ils n’étaient jamais sûrs de commander la bonne taille. Ils ont cherché des outils pour régler cette problématique. Ils n’ont rien trouvé. C’est ainsi que leur est venue l’idée de monter cette application. 

Dès le début de ce projet, nous nous sommes consacrés au secteur du prêt-à-porter. Notre objectif premier était d’aider nos partenaires à recommander la bonne taille à leurs utilisateurs. Sur leur site e-commerce, et plus précisément sur leurs fiches produits, nous installons notre plugin via un bouton d’action. Lorsqu’il clique sur ce bouton, l’utilisateur doit renseigner plusieurs informations morphologiques (son sexe, son âge, sa taille et son poids). Ces données sont croisées avec les informations techniques de la marque afin de lui fournir une recommandation sur la taille la plus juste. 

Initialement, Fitizzy fournissait aux utilisateurs des recommandations de taille sur un produit donné. Désormais, nous allons plus loin en proposant des recommandations de produit en fonction de votre morphologie. Aujourd’hui, nous mettons ces services à disposition de plus d’une cinquantaine de marques dans le secteur du vêtement et de la chaussure.

Cette application permet clairement de mettre l’internaute en confiance lors de son achat en ligne – il a moins peur de se tromper lors du choix de la taille. De plus, elle réduit considérablement les retours clients suite à une commande en ligne. Ces retours, gratuits pour le consommateur, sont très coûteux pour le distributeur. 

À côté de cela, depuis deux ans, nous avons ouvert un nouveau marché dédié aux vêtements professionnels. De plus en plus d’entreprises ont besoin d’habiller leurs employés. Jusqu’à présent, ces entreprises passaient par des sociétés qui mandatent des agents chargés de relever sur place les mensurations de chaque employé.

Pour réduire ces coûts de déplacement, nous avons eu l’idée de créer une plateforme dédiée à la prise de mensuration. Sur cette plateforme, les employés remplissent un formulaire et nous informent sur leur morphologie. En fonction de ces informations collectées, nous produisons des recommandations de taille. Ainsi, il y a moins d’erreurs dans le nombre de modèles à produire, et les frais de gestion et livraison sont réduits.

Dans ce secteur, nous travaillons notamment avec Bragard, leader dans les vêtements professionnels pour la cuisine, les métiers de bouche et l’hôtellerie, ainsi qu’avec CWS-Boco, spécialiste dans les vêtements de chantier. »


Des architectures plus souples et plus flexibles grâce à AWS

« Notre application a basculé sur le cloud d’AWS il y a plus de deux ans. Il y avait un grand intérêt à faire ce pas car, à l’époque, nous travaillions encore sur des serveurs hébergés. Du coup, nous n’avions pas toute la souplesse qu’offre AWS et leurs services managés. La conception des nouvelles architectures était plus laborieuse, demandait plus de temps. Et le résultat était souvent plus coûteux que ce que peut nous apporter AWS aujourd’hui. »


Une migration pas à pas 

« Lorsque vous migrez une application sur AWS, trois possibilités s’offrent à vous. 

Soit vous prenez l’existant et vous essayez de le faire entrer tel quel dans AWS. Cela est possible. Il s’agit de la méthode « lift and shift ». Mais, elle coûte cher, car vous n’utilisez pas les fonctionnalités natives du cloud. 

Soit vous repensez toute l’architecture et le code de votre application afin de pouvoir optimiser au maximum les fonctionnalités natives du cloud. On parle alors de « refactoring ».

Dans notre cas, nous avons choisi un entre-deux, nous avons opté pour le « replatform ». Cette méthode permet de tirer parti des fonctionnalités de base du cloud, d’optimiser les coûts, sans engager un niveau de ressources élevé. Ainsi, lors de cette migration, épaulés par l’équipe de premaccess, nous avons pris le temps de préparer les grandes briques de notre application avant d’investir AWS, en évitant le simple « copier-coller ».

Nous avons  :

  • le coeur central, autonome, consacré à notre API.
  • puis nos services, le plugin, nos applications, les plateformes, tout ce qui est « web ». Ces éléments sont indépendants du coeur central.
  • Enfin, nos bases de données. »

Utiliser les données pour améliorer les services e-commerce

« La gestion des données est cruciale dans Fitizzy, notamment pour améliorer nos recommandations. Aussi, lors de notre bascule sur AWS, nous avons investi Amazon Kinesis et la chaîne de services suivants : S3 + Athena + QuickSight grâce au soutien des équipes de premaccess

Kinesis est un service managé permettant de collecter, trier et analyser des datas stratégiques des sites marchands de nos partenaires. Pour chacun de nos clients, nous analysons les pages vues, les clics sur notre bouton d’action, l’ouverture de notre plugin, le contenu de notre recommandation, l’ajout au panier, l’achat ou l’abandon de panier. En croisant l’ensemble de ces informations, nous cherchons à affiner nos outils.

L’ensemble de ces données sont mises à disposition de nos clients grâce au service Amazon QuickSight. Via un Dashboard dédié, chaque partenaire retrouve l’ensemble de ces datas sous forme de graphiques. Ces KPIs peuvent être utilisés par son service marketing pour améliorer les performances de son site e-commerce. Elles peuvent également être intéressantes par ses modélistes pour optimiser les nouvelles collections en analysant les données morphologiques du moment. »


Les + de premaccess : l’analyse des enjeux, la maîtrise des coûts et l’expertise AWS

« La force de premaccess tient dans son expertise dans le domaine du développement logiciel, des services managés d’AWS et de la migration. Lorsque nous nous sommes penchés sur ce projet de migration, son équipe a avant tout évalué nos enjeux.

Au-delà de « Est-ce que nous migrons sur AWS ? », notre réflexion s’est plutôt portée sur « Est-ce que cela vaut le coup que nous le fassions maintenant sur AWS et de cette manière ?

Est-ce rentable pour nous de recruter des ressources pour faire ce travail maintenant ou est-ce que cela vaut le coût d’attendre quelques semaines quand nous aurons plus de ressources, plus de budgets ? »

Avant même cette migration, premaccess nous a accompagné sur cette dimension « business » afin que nous optimisions nos finances.

En second temps, ils nous ont énormément conseillé dans le travail préparatoire à la migration, et dans la mise en place du plan d’action. Clairement, même si je suis développeur, je n’avais pas du tout d’expérience sur le cloud d’AWS. Leur participation sur le plan d’action a été très précieuse.

Enfin, une fois le plan de migration validé, une partie de la bascule sur AWS a été réalisée en interne avec le soutien de l’équipe de premaccess. Ils ont aussi pris en charge la partie « Landing Zone et Sécurité » de notre espace sur AWS (création d’utilisateurs, gestion des droits, préparation du réseau et des couches réseau, etc.). Ils l’ont déployée via leur solution SaaS BAM que nous utilisons désormais tous les jours pour nos environnements temporaires.

En partant d’un template bien défini, cet outil crée très rapidement des environnements parfaitement configurés. De quoi nous faire gagner beaucoup de temps. 

Par ailleurs, nous sommes toujours en quête d’efficience. Nous cherchons à normaliser nos technologies sur nos différents projets, à faire en sorte que nos cycles de développement soient similaires d’un projet à un autre. Cela est aujourd’hui facilité avec BAM. Cet outil nous assure une automatisation des processus, et ne laisse aucune place à l’erreur humaine.

Ainsi, nous nous concentrons davantage sur notre développement, sur notre coeur de métier. En tant que développeur, grâce à cette solution, je passe plus de temps à créer des fonctionnalités, à enrichir notre partie business qu’à mettre en place les infrastructures techniques pour nos applications. »


Prochain challenge : proposer Fitizzy en mode SaaS

« Désormais, notre prochain challenge sera de rendre Fitizzy complètement SaaS. Ainsi, n’importe quelle marque pourra configurer notre solution à travers notre interface sans même avoir besoin que nos équipes interviennent. L’idée est aujourd’hui mature. Les premières briques commencent à arriver. 

Clairement, ce nouveau projet aurait été bien difficile à mener sur notre ancienne infrastructure. Grâce à cet investissement sur le cloud d’AWS, il est désormais à notre portée, et ouvre de nouvelles perspectives. 

Dans le développement de Fitizzy, premaccess est aujourd’hui plus qu’un partenaire technique. Son équipe a une telle connaissance du développement logiciel avec AWS qu’elle nous aide à améliorer notre business et étoffer notre offre. Je pense notamment à ses conseils sur les services managés liés à la gestion des données et le serverless. De quoi avoir un coup d’avance et toucher de nouveaux marchés. »



Aller plus loin

Voici quelques services managés d’AWS utilisés par Fitizzy