
Bien plus qu'une simple tendance, le numérique responsable est une nécessité, nous devons repenser le numérique pour un avenir plus respectueux de l'environnement et des personnes. 

Trop souvent négligée, l’empreinte environnementale et sociale du numérique doit nous alarmer sur nos pratiques et habitudes. 

**Mais peut-on vraiment associer les mots numérique et responsable ?**

**Que peut-on faire pour tendre vers un numérique plus responsable ?**

## Un numérique irresponsable
Le numérique, souvent considéré comme immatériel, cache en réalité une empreinte écologique et humaine significative.


### Les impacts du numérique sur la planète 
Chaque étape du cycle de vie d’un appareil numérique a un impact sur l’environnement de sa fabrication jusqu’à sa fin de vie, en passant par son usage évidemment.

#### L'émission de gaz à effet de serre
Le numérique contribue à environ 4% des émissions mondiales de gaz à effet de serre et ce chiffre est en augmentation de 8% par an. Pour mettre en perspective, le transport aérien représente 2,5 % et le transport automobile 6%*, le numérique pollue donc plus que nos voyages en avion.

#### L’énergie utilisée
Nos usages numériques, incluant data centers, terminaux et infrastructures, représentent 7,5% de notre consommation d'électricité. La vidéo en ligne correspond à 60 % des flux de données mondiaux et la production des terminaux représente presque 50% de la consommation énergétique du numérique !*

#### L’exploitation des ressources en matière première et eau
La fabrication de nos outils numériques a un impact majeur, à titre d’exemple : 200 kg de matière première sont nécessaires pour fabriquer un smartphone de 200 g et chaque tonne de terre nécessite l’utilisation d’au moins 200m3 d’eau* N’oublions pas que l’eau est également utilisée pour refroidir les data centers qui hébergent nos données. En tout, le numérique consomme 7,8 millions de m3 d’eau douce par an.




### Les impacts du numérique sur les humains
Exploitation des biais cognitifs, manipulation des algorithmes, économie de l’attention, désinformation, le numérique a un grand pouvoir sur la société...

#### Besoins vitaux et sociaux 
80% des adultes passent plus de 3 h par jour devant un écran avec pour conséquences : la perturbation des rythmes biologiques, l’augmentation de la sédentarité et de l’inactivité, troubles de l'apprentissage ou encore cyber-harcèlement.

#### Libertés
Les fake news se répandent 6 fois plus vite que les vraies informations qui favorisent de plus en plus la polarisation des idées et la désinformation. Par ailleurs, certains services numériques exploitent les dark patterns (design trompeurs en français) et jouent avec nos biais cognitifs pour nous manipuler. Snapchat, en encourageant les interactions quotidiennes avec des récompenses (les flammes), en est un parfait exemple, nous rendant volontairement dépendants. 

#### Inclusion et diversité
24% des 15-64 ans sont en situation de handicap au sens large pourtant seulement 5% des sites internet sont accessibles et 1 personne sur 6 en France n'a pas utilisé internet au cours de l'année 2019. Sans commentaire…

### Mais ça s’améliore non ?
Non, pas vraiment. 😅

Le nombre d’internautes est en constante augmentation et ils ont de plus en plus d'équipements. Le poids des pages web suit le même chemin, entre 1995 et 2022 il a été multiplié par 155 et ne cesse d’augmenter*. Pour faire simple : réserver un billet de train transporte au moins 3 fois plus d’octets qu’il y a 10 ans pour faire exactement la même chose ! 

Cette augmentation du poids des pages web s'accompagne d'une exigence croissante de puissance des terminaux, raccourcissant leur durée de vie "en bonnes conditions" et incitant les utilisateurs à les remplacer plus fréquemment. D’autant que **c’est la fabrication du matériel lui-même qui représente le plus d’impact.**

La fabrication des outils numériques a également des répercussions humaines. La fabrication nécessitant des minerais rares comme le cobalt et le coltan, leur exploitation dans les mines génère des conflits politiques et des conditions de travail inhumaines impliquant des enfants.

Le numérique a permis de grandes avancées mais a aussi des conséquences beaucoup moins souhaitables : un impact environnemental massif et grandissant, des inégalités entre utilisateurs ainsi qu’un problème d’éthique évident. 

**Heureusement, des solutions existent pour tendre vers un numérique plus responsable !**

## Qu’est-ce que la conception de services numériques responsables ?
Frédéric Bordage de l’association Green IT, la définit ainsi « la conception de services numériques plus performants d'un point de vue environnemental, économique et social ». Le Numérique Responsable vise à concevoir  un service numérique guidé par les 3P : People, Planet, Prosperity (personnes, planète, prospérité), ils font écho aux 3P du développement durable People, Profit, Planet.

### Personnes
Prendre en compte l’aspect social du numérique, l’impact qu’il peut avoir sur les personnes. Il est question ici d’éthique et de respect des utilisateurs mais également de diminution de la fracture sociale par, entre autres, l’accessibilité des services.

### Planète 
Créer un service numérique le plus sobre possible afin de réduire l’empreinte environnementale du numérique. Pour cela, il est nécessaire d’éco-concevoir nos produits et services numériques ainsi que nos infrastructures.

### Prospérité
Penser un service au-delà de sa valeur économique, mais bien en considérant la valeur que celui-ci apporte aux personnes et à la planète. Cela passe par la prise en compte des leviers du développement durable lors de la conception du service.


## Quels sont nos leviers d’action ?
Le Numérique Responsable intervient à chaque étape du cycle de vie d’un service numérique, de sa conception jusqu’à la gestion de sa fin de vie. Nous avons de nombreux leviers d’action, en voici quelques-uns.

### Penser inclusion et accessibilité
Sur le web, nous ne partons pas tous avec les mêmes facilités. C’est pourquoi il est essentiel de comprendre et de répondre aux besoins de tous les utilisateurs, quel que soit leur âge, leur niveau de compétence technologique, leurs capacités physiques ou leur équipement. Souvent réduite à des contraintes légales liées au handicap, l’accessibilité n’est que rarement respectée, cela est certainement dû à des préjugés et à un manque de sensibilisation parmi les professionnels du web et les porteurs et porteuses de projet.

**L'accessibilité et l'inclusion numériques ont pour but de garantir à chaque utilisateur une expérience web optimale.**

### Éco-concevoir nos services numériques
Afin de minimiser l'impact environnemental des sites et applications web à toutes les étapes de leur existence, ces derniers peuvent être éco-conçus. 
Il faut savoir qu’environ 45% des fonctionnalités demandées ne sont jamais utilisées, et 70% ne sont pas essentielles. La définition du besoin et des fonctionnalités est donc une étape essentielle avec un impact fort. L'éco-conception nécessite également des choix judicieux en matière de design, d'interface, de code, d'infrastructure et d'hébergement. 

**Cette approche permet de créer des interfaces plus légères, efficaces et performantes, tout en prolongeant la durée de vie des appareils utilisateurs.**

### Proposer un service éthique
Tout simplement en concevant des interfaces respectueuses des utilisateurs et de leur vie privée, sans essayer de les manipuler en exploitant leurs biais cognitifs pour répondre à des objectifs commerciaux. Nous pouvons concevoir en veillant à minimiser les intrusions et en évitant de renforcer leur dépendance à nos applications. Et bien évidemment respecter leurs données personnelles. 

**En bref, en concevant POUR nos utilisateurs et utilisatrices et non contre eux et elles.**


## Engagez-vous pour un numérique plus responsable avec Troopers !
En tant qu'agence web et professionnel·les du numérique, nous avons la possibilité, et la responsabilité, de contribuer au développement d’un numérique plus responsable. 
Chez Troopers, nous défendons le numérique responsable aussi bien dans nos métiers que dans nos engagements et notre environnement de travail.



**Prêt·es à vous engager aussi ?**

**Nous vous donnerons, dans un prochain article, les clés pour vous aussi amorcer cette démarche.**

**Ensemble, construisons un numérique plus responsable !**




_*Sources : INR, GreenIT, Shifters, Latitudes, Amnesty International, Ademe._

Pourquoi devons-nous tendre vers un numérique plus responsable ?

[Nous aimons utiliser Sylius](https://troopers.coop/expertises/sylius) comme plateforme pour développer des sites e-commerce, des sites de vente, des marketplaces, ou même des ERP !




C’est un excellent outil, très évolutif. Il est possible de modifier son fonctionnement en profondeur tout en conservant la puissance du framework et la possibilité de continuer à le mettre à jour pour bénéficier de nouvelles fonctionnalités.
Mais parfois, une modification anodine a des conséquences inattendues…

## L’apparition du problème

Lors d’un sprint récent sur un projet basé sur Sylius, Patrick le PO remonte une erreur lors de la modification d’un produit. Il n’arrive pas à valider la modification d’un produit alors que cela marchait auparavant.
Étrange, c’est le même formulaire qui permet la création et la mise à jour d’un produit. Il a été modifié il y a peu et des tests automatisés ont été mis en place.

Il n’y a pas à tergiverser, lorsque l’on cherche à modifier certains champs, le site remonte une erreur :
“Mise à jour impossible, Product a été modifiée précédemment” ou “Cannot update, the Product was previously modified” selon les préférences de langue.

Les tests automatisés n’ont pas détecté le problème : ils ne couvrent que la création du produit, pas sa modification.

## Que nous révèle cette erreur ?

En première approche, j’aime faire un rapide tour dans le code. En restant naïf on a parfois de bonnes surprises, et des réponses rapidement. Le message d’erreur semble suffisamment unique pour commencer par là.



Une recherche dans le code fait remonter que ce texte est associé à la clé de traduction “race_condition_error”.
Nouvelle recherche : cette clé n’est utilisée qu’au sein d’une exception spécifique à Sylius (RaceConditionException), elle-même est utilisée dans une seule classe : Sylius\Bundle\CoreBundle\Doctrine\ORM\Handler\ResourceUpdateHandler

Ouch ! Ça parle de Doctrine, qui fait l’interface entre notre code et la base de données. Dans ce contexte, une erreur de “race condition” signifie que le code ne parvient pas à déterminer dans quel ordre traiter une ou plusieurs demandes de mise à jour : la donnée en base peut être plus récente que la modification que l’on envoie.

Cela ne s’annonce pas trivial : il est temps d’identifier la modification qui a fait apparaître l’erreur.

## Comment trouver le commit coupable ?

On a identifié un champ qui génère l’erreur lors de la modification d’un produit. J’écris un test simple : créer un produit, puis tenter de modifier ce champ. Le test échoue car l’erreur apparaît.

Je vais remonter dans le temps à l’aide de GIT, l’outil de gestion de version que nous utilisons. Mon objectif : utiliser le test pour déterminer quel commit a fait apparaître l’erreur.

Je pourrais utiliser la commande [git bisect](https://git-scm.com/docs/git-bisect) qui remplit parfaitement ce rôle. Mais j’ai ma petite idée du commit “coupable” :
- Je remonte l’historique GIT juste avant le commit : le test passe.
- J’avance d’un commit, le test échoue. Parfait, c’est bien là que tout se joue !

## Identifier le problème

Dans ce commit, on a ajouté des champs sur deux entités : Product et ProductVariant.

- Product, vous l’aurez deviné, représente un produit.
- ProductVariant représente un produit particulier, avec ses propres options, sa propre tarification, voire son propre suivi des stocks.



En plus de l’ajout de ces champs, les formulaires ont été modifiés pour les afficher, et au passage intégrer le design du projet.

J’annule les modifications sur ProductVariant, et je retire les champs associés dans les formulaires. L’erreur est encore présente. Mauvaise pioche ?

Je recommence avec les modifications de l’entité Product… L’erreur persiste.

On a toujours la “RaceConditionException”, due à la mise à jour d’une entité en base de données. Or je viens d'annuler tout ce qui a changé dans le code qui concerne les entités Product et ProductVariant. Soit je suis entré dans la quatrième dimension, soit j’ai raté quelque chose.



Que reste t’il dans le commit ? Une innocente modification esthétique : nous n’affichons plus la gestion des stocks lors de l’édition du produit car c’est inutile pour ce projet.

Dans le doute, j’annule cette modification : l’erreur disparaît !

## La réponse, et le correctif

En supprimant l’affichage de la gestion des stocks, nous avons cassé l’édition des produits.

Comment est-ce possible ? Le formulaire en question ne présente que deux champs : *faut-il suivre les stocks* et si oui, *quel est le stock actuel*…

Et pourtant, un troisième champ est bien présent (mais invisible pour l’utilisateur) : la *version*. Il n’est pas obligatoire, mais son absence semble poser problème.
Je ne sais pas ce qu’est cette *version* de la variante. Avant de creuser cette piste : testons. 

Si je l’affiche (toujours invisible) mais sans rétablir la gestion des stocks, l’erreur ne réapparaît pas. Bingo, voici le correctif : rétablir le champ *version* dans le formulaire, bien qu’il ne soit pas visible.

## Mais, pourquoi ?

Ce système de version sur ProductVariant est présent pour éviter que plusieurs demandes de modifications simultanées ne rentrent en conflit. D’accord, mais pourquoi est-ce que le champ se retrouve enfoui avec la gestion des stocks, s’il est si important ?

Avec le système des stocks, il va y avoir une modification de la variante à chaque fois qu’un produit est vendu. Si deux clients achètent le même produit au même moment, ils vont tous deux demander une modification “stock -1” avec la même version : 
- Le système s'appuiera sur la donnée version pour n’autoriser qu’une modification.
- La seconde modification sera rejetée, puis retentée avec la nouvelle version : s’il reste du stock, l’achat sera également validé. Si non, pas de chance, le produit vient de passer en rupture de stock.

Comme le champ de formulaire est caché, il peut être généré n’importe où dans la page.
Bien que j’aurais préféré qu’il soit ajouté avec les champs cruciaux de la variante, je peux comprendre comment il s’est retrouvé associé aux champs de formulaire liés aux stocks…

## Le(s) mot(s) de la fin

Ce bug aura été l’occasion de creuser un peu plus loin dans notre connaissance du framework Sylius et de ses composants les moins apparents, comme le versionnage des entités.

Le problème peut sembler lunaire : des erreurs liées à Doctrine, la persistance en base, RaceConditionException. Mais l’approche de résolution montre encore une fois sa pertinence : reproduire l’erreur, réduire les modifications jusqu’à trouver l’élément déclencheur, étudier cet élément pour comprendre pourquoi il pose problème et comment corriger.

Comme à chaque fois qu’un bug échappe aux tests automatisés écrit par les développeurs, nous nous posons la question : avons-nous la bonne approche pour la rédaction des tests ?
Les tests sont nécessaires mais peuvent être chronophages (écriture, maintenance, exécution). Lorsque l'on travaille avec un framework, on cherche à tester “notre” code, pas celui du framework car il est déjà testé : c’est une perte de temps.
Ici, fallait il d’emblée un test automatisé sur la mise à jour, en plus de la création ? Sachant que le même code est concerné dans les deux cas, j’ai tendance à penser que non.
Par contre, maintenant que le bug a été rencontré, le test créé pour réussir à l’isoler et à le corriger va rester dans notre suite de tests. On a pu se faire surprendre une fois, mais pas deux !

Un bug cache parfois une occasion de mieux découvrir votre framework préféré

Lorsque je commence un projet ou réponds à un appel d’offres, la lecture du cahier des charges est une **activité à récompense variable**. Trop léger, je crains que le client ne se lance tête baissée dans un projet aux contours flous ; trop rempli, je crains que la description du besoin soit figée.

Dans les deux cas, le **format écrit peut donner lieu à des interprétations différentes** et apporter plus de questions que de réponses. La communication finit par ressembler à une partie géante de Gartic phone, le jeu favori des Troopers pendant le Covid.

Cet écart est la raison pour laquelle je propose systématiquement de commencer la phase de cadrage par la **création d’une story map**.














## Qu’est-ce qu’une story map?
**Une story map est tout simplement la carte des besoins utilisateurs**. C’est aussi le livrable de l’atelier de story mapping qui est une méthode de description des besoins utilisateurs **de manière visuelle, chronologique et priorisée**. Concrètement la story map est un tableau géant de post-it qui permet de comprendre d’un coup d'œil ce que fait un utilisateur dans l’outil qu’elle décrit.

## Comment faire une story map ?
La **story map ressemble à une pièce de théâtre** : 
- les personnages sont appelés personas ;
- ils vivent des aventures que l’on appelle des récits utilisateurs ;
- ces récits sont regroupés dans des chapitres, appelés epics ;

Les chapitres ou récits ont lieu dans des décors, vous l’avez deviné ce sont les interfaces du logiciel et elles ne sont pas visibles en tant que tel dans la story map.

Prenons une pièce de théâtre dont vous êtes le héros quotidien : se préparer le matin.  Voici les epics :
- se lever ; 
- se laver ;
- s’habiller ;
- manger.   

Les récits utilisateurs possibles pour “se lever” sont :
- éteindre son réveil ;
- faire son lit ;
- ouvrir les volets ;
- faire quelques étirements.

## Avantages du story mapping
### Aligner les participants d’un projet sur une vision
Lors des ateliers de story mapping que j’ai pu animer, j’ai toujours constaté qu’il y avait plusieurs livrables. Le premier est bien sûr la story map, mais le second est plus surprenant.

Lorsque plusieurs personnes se mobilisent quelques heures pour imaginer leur futur outil, cela fait émerger toutes les **incompréhensions et angles morts du début de projet**. Mieux vaut que ces discussions aient lieu le plus tôt possible, et surtout avant la livraison ! Le format de l’atelier aide beaucoup et facilite les arbitrages avec la phase de priorisation.

Le choix des participants est donc primordial et c’est pour cela que j’insiste toujours pour faire venir de futurs utilisateurs, ou des personnes a priori non concernées comme le personnel administratif de l’entreprise.




### Communiquer facilement sur un projet complexe 
Le second avantage d’une story map est sa lisibilité. Le format de rédaction d’un récit utilisateur est compréhensible et exprime à la fois la solution et le besoin. 
- En tant que Troopers, je mange un fruit afin d’avoir de l’énergie.

Exemple plus réaliste : 
- En tant que comptable, j’exporte la facture afin de la partager au client.

Alors qu’un cahier des charges se lit, **une story map se consulte et se discute**. Cette discussion fait émerger de nouveaux post-it qui viennent alimenter la story map.

Au contraire, dans un cahier des charges, des synonymes ou des formulations peuvent créer des incompréhensions qui se révéleront désastreuses pour le projet. Cette phrase résume bien ma pensée : “Il nous arrive de considérer que tout ce que nous écrivons est clair et limpide. C’est parfois vrai et souvent faux.*”

### Prioriser son projet avec le story mapping
Lors de la création de la story map, différentes solutions émergent pour un même besoin. Pour reprendre l’exemple de votre début de journée, pour l’epic “manger” certains vont passer une demi-heure à table tandis que d’autres se contentent d’un fruit. Mais si vous savez déjà que vous êtes en retard pour aller au travail, vous allez sûrement vous contenter d'un ~~pain au chocolat~~ fruit !

L’option “fruit” devient une V1 (version 1) et “petit-déjeuner complet” une V2. Le petit déjeuner V2 sera possible une fois que la V1 est sécurisée et s’il reste du temps après que toutes les autres epics de la V1 soient finies.

Nous utilisons la même logique pour créer un logiciel : prioriser la **version qui répond au besoin en prenant le moins de temps possible**. Une fois que cette priorisation a eu lieu vient l’estimation. L’une des **grandes lois du développement logiciel** est “qu'il y a toujours plus à créer qu'il n'y a de personnes disponibles, de temps et d'argent à y consacrer.” Je fais donc estimer par l’équipe de développement la V1 de la story map.

Une fois le résultat obtenu, je sais si le budget est suffisant pour livrer toute la V1, si c’est le cas alors certains récits ou epics  relégués en V2 pourront être conçus.

### Et l’éco-conception dans tout ça ?

Le story mapping est un très bon allié pour réduire l'impact environnemental de son projet. Le référentiel général d’écoconception des services numériques (RGESN) préconise en effet de :
- définir les cibles utilisatrices (critère 1.2) ;
- leurs besoins et attentes réelles (1.3) ;
- et d’optimiser leurs parcours (4.4).

Pas de problème ! La conception d'une story map nécessite toutes ces actions, notamment l’optimisation du parcours utilisateur, pour lequel on livre une V1 avant d’ajouter des fonctionnalités de confort.

## Inconvénients du story mapping
### La story map et les sujets techniques
Parfois, un système ou une fonctionnalité doit être créée sans qu’elle n’ait aucune interface utilisateur. C’est le cas d’un algorithme de rapprochement de candidats et d’offres d’emploi ou un mécanisme de génération de commandes.

Dans ces cas-là, je trouve que la story map est plus difficile à manier. Je finis généralement par créer un post-it recensant le fonctionnement complet. La réalité est que **l'approche agile trouve ses limites dans ce cas**. Un système qui n’est codé que sur la base de besoins exprimés manque un peu de vision. Il faut aller plus loin **en anticipant tous les cas possibles et en s’inspirant de solutions existantes**.

### Estimation et budget
La story map est en revanche **plus dure à estimer aussi finement qu’un cahier des charges** car la description des besoins est moins fine. Les récits utilisateurs sont en effet complètement décrits au fur et à mesure du projet alors que dans un cahier des charges le fonctionnement est figé avant le début du développement.

Faut-il faire un cahier des charges ou une story map ? Pour une **prestation au forfait**, elle garde sa pertinence pour aligner les parties prenantes, éviter les découvertes en cours de projet et faciliter le suivi du développement. Pour les **produits gérés en agilité**, j’organise des ateliers d’Extreme Quotation pour obtenir des estimations et répartir l’effort sur le planning.

Si une story map est simple à comprendre, en créer une demande un peu d’expérience et je conseille de faire appel à une personne expérimentée pour l’animer. Cet atelier fait souvent émerger des **visions contradictoires** et un facilitateur externe aidera à **faire de cet atelier une pierre fondatrice du produit**.

*Culture produit, Octo, Samuel Retière - Xaviera Meyer Bosque - Benoit Ricaud

Comment prioriser son projet avec une story map ?

La publication d'une application sur App Store et Google Play Store nécessite de nombreuses heures de travail : il faut installer des outils complexes sur notre machine, compiler l'application pour les 2 boutiques d'application, puis transférer les fichiers, et enfin les envoyer pour qu'elles soient validées.

Heureusement Expo nous aide à réduire ces étapes au strict minimum.

Expo nous permet d'utiliser encore plus facilement des librairies de React Native :

- Permissions
- Géolocalisation
- Sélecteur d’images
- Signatures
- Notifications

EAS (Expo Application Service) est un service d'Expo qui permet de publier facilement sur les deux stores en suivant ces étapes : Gitlab → Expo → App Store.

Grâce à GitLab CI et à Expo, nous n’avons plus besoin de compiler l’application nous-mêmes, ce qui était contraignant en particulier pour iOS car il nous fallait un Mac disponible et éviter les écueils lors de l’installation de Xcode.

## Mise en place

Pour cela nous sommes passés par ces phases :

1. Configuration EAS pour branchement App Store
2. Configuration dans GitLab CI
3. Pas de configuration particulière dans App Store
4. Pas d’automatisation vers le PlayStore mais un simple fichier APK à envoyer sur la console Google Play Store

Configuration dans GitLab CI :

```yaml
.eas: &eas
 image: ghcr.io/troopers/node-14-eas:latest
 stage: build
 before_script:
   - yarn install
 when: manual


build-android-preprod:
 <<: *eas
 script:
   - yarn eas build --platform=android --profile=preprod --no-wait --non-interactive
 only:
   - develop


build-ios-preprod:
 <<: *eas
 script:
   - yarn eas build --platform=ios --profile=preprod --auto-submit-with-profile=release --no-wait --non-interactive
 only:
   - develop


update-preprod:
 <<: *eas
 stage: update
 script:
   - yarn eas channel:create preprod || true
   - yarn eas channel:edit preprod --branch develop || true
   - yarn eas update --non-interactive --branch=develop --auto
 only:
   - develop
```
  
  
 Le job **build-android-preprod** envoie les données à EAS qui va compiler l’application et nous fournir un lien vers un fichier APK qui peut être partagé et installé sur un appareil Android.

Le job **build-ios-preprod** envoie les données à EAS qui va compiler l’application et l’envoyer directement dans Testflight, on pourra alors publier cette version pour les utilisateurs qui font partie de notre groupe de testeurs.

Le job **update-preprod** sert quant à lui à pousser une mise à jour en OTA. Puisque la mise à jour ne demande pas de compiler l’application, la mise à jour est très rapide, elle est effective en moins de 5 minutes (contre 10 à 15 minutes pour les compilations Android et iOS).

Côté Expo, on peut visualiser comment chaque branche de git est connectée à un environnement Expo :

Récemment nous avons mis à jour la version d’Expo sur l’un de nos projets pour installer la version 45.

Cette version 45 a débloqué Expo Go et donc les mises à jour OTA très faciles, y compris via un QR code.

Les mises à jour OTA nous autorisent à mettre à jour l’application à l’exception des couches natives de l’application : configuration de base, dépendances écrites en code natif, etc.

Les publications OTA sont parfaites pour les mises à jour urgentes, par exemple pour une mise à jour pour avoir tout le monde sur le même niveau d’API. Une fois qu’une mise à jour OTA est publiée, Expo s’occupe de télécharger la mise à jour. Les utilisateurs et utilisatrices n’ont alors qu’à redémarrer leur application pour utiliser la nouvelle version.

Nous mettons quand même à jour la version sur les boutiques Apple et Google afin que les nouveaux utilisateurs aient directement la dernière version.
## Conclusion

Expo permet de publier sur les deux stores via EAS en allégeant la charge de travail. Il vient avec des avantages et des inconvénients et c’est un choix d’architecture important. Le nombre et la spécialisation des développeurs, le temps à accorder au projet aux phases de déploiement doivent jouer dans ce choix.


Comment s’appuyer sur Expo pour publier sur les deux app stores ?

## Comment nous utilisons Sylius pour construire des e-commerces open source et sur mesure
 
Chez Troopers, nous construisons des sites e-commerces, des marketplaces ou des outils de gestion pour nos clients. Pour cela, nous utilisons [Sylius](https://troopers.coop/expertises/sylius). Dans cet article nous vous partageons :
- ce qu’est Sylius, ses **principales fonctionnalités et avantages** ;
- et plusieurs **projets clients utilisant Sylius**, qu'ils soient passés ou en cours.

## Sylius : zoom sur cette solution open-source

### Présentation de Sylius

Sylius est une plateforme e-commerce open source basée sur le framework PHP Symfony. Lancée en 2011, elle est conçue pour offrir une **solution flexible et configurable aux entreprises qui souhaitent créer une boutique e-commerce**.

Sylius se distingue de ses concurrents grâce à sa **modularité** et sa capacité à s’adapter à différents types de projets et tailles d’entreprises.

En tant que solution open source, Sylius bénéficie d’une **large communauté de développeurs** qui contribuent à l’amélioration et au développement des fonctionnalités.

Une vaste bibliothèque de **plugins et d’extensions peut être utilisée pour ajouter des fonctionnalités spécifiques** à un site ou une application e-commerce : **liste de souhaits, gestion avancée de contenus éditoriaux** et j’en passe.

### Quelques caractéristiques intéressantes de Sylius 
#### La taxonomie
Sylius simplifie la gestion de l’arborescence des produits grâce à son système de taxonomie : des **catégories hiérarchisées** qui permettent de classer les produits. Sylius se charge alors de générer menus, filtres et pages catégories pour que les utilisateurs puissent aisément naviguer dans votre site e-commerce et découvrir les produits.

Les utilisateurs de Sylius peuvent facilement créer, modifier ou supprimer des catégories sans avoir de compétences en développement.

#### Personnalisation des cycles de la commande
Sylius offre la possibilité de **personnaliser les différentes étapes du processus de commande**.

En plus des étapes classiques telles que “en cours de préparation” ou “expédié”, il est possible d’ajouter des étapes supplémentaires et de** créer des règles sur mesure**. Par exemple, pour des produits personnalisables, une étape “en cours de fabrication” peut être ajoutée.

Cela apporte une valeur ajoutée aux clients en améliorant la transparence et facilite le suivi pour l’entreprise. Sylius gère également les retours de commandes de manière efficace.

#### Solutions de paiement et d’expédition
Sylius permet de **connecter la boutique e-commerce avec différents outils de paiement et d’expédition**. Certaines des solutions de paiement compatibles incluent PayPal ou Stripe. Pour les livraisons, Sylius peut se connecter avec les différentes solutions d’expédition. 

Intégré à Sylius, il est possible d’utiliser Payum, une bibliothèque de paiement open source qui facilite et sécurise l’intégration des **passerelles de paiement** dans les applications e-commerce. Elle offre une interface unifiée pour interagir avec les différents services de paiement et simplifie le processus de développement en gérant les détails techniques de chaque passerelle.

#### Personnalisation de la boutique e-commerce et/ou du back-office 
Il est possible d’utiliser la boutique en ligne et le back-office de Sylius par défaut ou de les personnaliser selon les besoins spécifiques de l’entreprise. Cela permet aux **entreprises de limiter les développements** dans un premier temps ou au contraire de créer une interface complètement adaptée à leur image. En adaptant le back-office, les entreprises peuvent ainsi calquer leur outil sur leurs processus internes et gagner du temps.



#### Solution open source et stable
Sylius est une solution open source, cela signifie que son code source est accessible à tous et peut être modifié pour répondre à des besoins spécifiques. Cela garantit une **solution flexible et évolutive** pour les entreprises.

De plus, Sylius bénéficie d’une communauté active de développeurs qui contribue à son amélioration continue et à sa stabilité. **Les entreprises sont assurées d’avoir une solution à jour et fiable pour leur boutique en ligne**.

### Les avantages de Sylius par rapport à ses concurrents

Sylius présente différents avantages par rapport à des solutions e-commerce comme Magento ou WooCommerce :
- **Flexibilité** : Sylius est conçu autour d’une architecture modulaire, permettant une personnalisation plus poussée et une meilleure adaptation aux besoins spécifiques de chaque entreprise par rapport à WooCommerce ou Magento ;
- **Performances** : Sylius est considéré comme une solution plus légère et rapide que Magento, ce qui se traduit par une meilleure expérience utilisateur et des temps de chargement plus courts pour les sites e-commerce ;
- **Facilité d’intégration** : Sylius est construit sur le framework [Symfony](https://troopers.coop/expertises/symfony), ce qui facilite l’intégration avec d’autres applications et services. WooCommerce, qui est un plugin pour WordPress, peut par exemple être plus complexe à intégrer avec des solutions tierces.

Le recrutement ou le recours à des développeurs est plus aisé sur Sylius qui est basé sur Symfony (avec une large communauté) alors que pour Magento, il faut trouver des développeurs spécifiques. Il faut noter que dans la plupart des cas la version gratuite de Sylius est utilisable pour lancer son projet.

## Notre utilisation de Sylius pour construire des e-commerces

Chez Troopers, nous utilisons Sylius pour construire des solutions e-commerce adaptées aux besoins de nos clients. Voici quelques exemples de projets sur lesquels nous avons travaillé avec succès en utilisant Sylius.

### Création d’une marketplace

Créer une marketplace peut être très complexe. En effet, cela implique de **gérer plusieurs vendeurs**, des catalogues de produits variés, des systèmes de paiement et de livraison distincts, voire des **commissions**.

Nous avons choisi d’utiliser le [plugin Odiseo](https://odiseo.io/plugins-and-bundles/premium/sylius-mvm-plugin) pour Sylius, cela nous a permis de bénéficier de nombreuses fonctionnalités clés-en-main qui nous ont permis de réduire considérablement la difficulté et le temps de développement d'une **marketplace producteurs-grossistes-détaillants**. 

Nous avons ainsi pu construire une **marketplace privée qui permet de mettre en relation les fabricants avec un groupe spécifique de clients**. Les acheteurs ont un compte pour accéder à la marketplace et sont associés à un type de profil qui leur permet d'accéder ou non aux catalogues des grossistes. Ainsi, les fabricants peuvent **filtrer les acheteurs et offrir une expérience d’achat personnalisée** selon leur cible commerciale.

### Site e-commerce proposant de la personnalisation de produits
Nous avons également construit un site e-commerce qui permet aux clients de personnaliser leurs produits lors de l’achat.

En utilisant Sylius, nous avons pu créer un processus de personnalisation interactif qui génère des consignes de fabrication spécifiques pour chaque client : la **commande validée sur le site déclenche automatiquement l’envoi des informations de fabrication du produit à l’usine** !

Ce système a permis de créer une **expérience d’achat unique** mais également d’optimiser le temps de traitement des commandes : en supprimant les temps d’attente entre l’achat en ligne et la fabrication en usine, les commandes sont **expédiées plus rapidement**. Cet avantage technique devient un argument commercial.

### ERP avec fonctionnalité de commandes récurrentes
Pour un de nos clients qui avait besoin d’une gestion des commandes récurrentes, Sylius nous a permis de **configurer et de mettre en place des abonnements qui génèrent automatiquement des commandes des clients** selon des règles définies lors du devis. Ce type de fonctionnalité est particulièrement utile pour les entreprises qui proposent des services ou des produits sur une base régulière.

En intégrant cette fonctionnalité à un système d’ERP, il est possible de **gérer les stocks et les ordres de préparation**, ainsi que l’ensemble du processus de commande depuis cette solution centralisée.



Ces différents exemples montrent des solutions e-commerce pouvant être développées avec Sylius.

## Pourquoi nous allons continuer à utiliser Sylius

Chez Troopers, nous nous engageons à fournir des solutions e-commerce sur mesure et adaptées aux besoins de nos clients.

Contrairement à certaines solutions e-commerce grand public qui peuvent être limitées en termes d’**adaptabilité et de personnalisation**, Sylius nous permet de répondre à cet engagement. Comme on l’a vu, c’est une solution e-commerce flexible qui offre de nombreuses fonctionnalités, ce qui en fait une option idéale pour **créer des sites ou applications e-commerce sur mesure**.

Sylius : la solution open-source pour un site e-commerce sur mesure


Quand on utilise API Platform pour servir un site front, on a souvent besoin d’un **espace d’admin** pour que les gestionnaires du site puissent gérer les données. Et généralement, c’est mieux si c’est pas fait de zéro. 


Dans notre recherche du bon espace admin pour notre API, nous avons eu l’occasion d’utiliser deux solutions : **Easy Admin** et la solution proposée et développée par **API Platform**.

Pour résumer brièvement, API Platform Admin est une application [**React**](https://troopers.coop/expertises/react) qui vient se connecter à votre API et la scanner pour proposer un ensemble de formulaires basés sur les endpoints disponibles. Easy Admin, quant à lui, est un **bundle** à ajouter à un projet [**Symfony**](https://troopers.coop/expertises/symfony) qui permet de créer de manière rapide un espace d’admin avec des formulaires correspondants aux entités. 

Notre but n’est pas de décréter lequel est le meilleur des deux, mais de vous proposer une comparaison afin que vous puissiez faire le choix le plus adapté à vos besoins.

## Api Platform Admin

C’est la solution officielle développée par les contributeurs d'API Platform, basée sur [react-admin](https://marmelab.com/react-admin/). Il s'agit d’une appli react qui analyse la documentation de l’API et génère des composants pour créer des formulaires d’administration. Les formulaires restent personnalisables en développant en React.

### Avantages

- Intégration complète avec Api Platform
- Conservation de la séparation API / front
- Pas de code pour la configuration par défaut
- Tous les widgets pour les types de base et les jointures sont disponibles
- Possibilité de personnalisation

### Inconvénients

- Devoir maintenir & héberger une application en plus
- S’il faut personnaliser, besoin de savoir développer en React
- Devoir mélanger les configurations de l’API front et admin sur API Platform, et gérer les droits qui vont avec

## Easy Admin

Easy Admin est un bundle qui, à l’instar d’autres outils tels que Sonata Admin, propose une interface d'administration des entités Symfony, à partir d’une configuration intégrée au projet. C’est un bundle symfony classique et nécessite donc de passer par un accès web au projet.
C'est donc une solution totalement décorrélée d’API Platform.






Pour cette solution, il est nécessaire d’écrire un peu de code afin de configurer
des formulaires pour les entités. Voici un exemple pour l’entité Question :
```php
class QuestionCrudController extends AbstractCrudController
{
   public static function getEntityFqcn(): string
   {
       return Question::class;
   }
  
   public function configureFields(string $pageName): iterable
   {
       return [
           IdField::new('id'),
           TextField::new('name'),
           TextField::new('company'),
           TextEditorField::new('description'),
       ];
   }
}
```
### Avantages 

- Environnement plus familier des développeurs back
- Installation facile et rapide
- Peu de code dans le cas nominal
- Décorrélé d’API Platform : réduction du risque d’effet de bord
- La commande Maker nous assiste afin de créer les classes

### Inconvénients

- Décorrélé d’API Platform : nécessite une configuration à part
- Obligé d’installer des dépendances inutiles à l’API (twig, etc.)

## Conclusion

En conclusion, le déploiement d’une nouvelle appli React peut s’avérer compliqué, tout comme la personnalisation d'éléments React en fonction des besoins du projet, si l’équipe n’est pas formée sur cette technologie, mais l’utilisation d’API Platform Admin permet une intégration plus cohérente de l’outil d’administration. C’est donc à décider en fonction de votre équipe de développement et de l'approche que vous souhaitez avoir pour votre projet.






Easy Admin vs Admin d'API Platform : comparatif des interfaces d'administration d'une API Symfony

Accueil

Retrouvez nos articles sur les dernières évolutions du monde du web

Le blog de Troopers

Pourquoi devons-nous tendre vers un numérique plus responsable ?

Un bug cache parfois une occasion de mieux découvrir votre framework préféré

Comment prioriser son projet avec une story map ?

Comment s’appuyer sur Expo pour publier sur les deux app stores ?

Sylius : la solution open-source pour un site e-commerce sur mesure

Easy Admin vs Admin d'API Platform : comparatif des interfaces d'administration d'une API Symfony