Tech-Ethic-E3B - 16:08:2021 15.01.mp3

Tech-Ethic-E3B - 16:08:2021 15.01.mp3: Audio automatically transcribed by Sonix

Tech-Ethic-E3B - 16:08:2021 15.01.mp3: this mp3 audio file was automatically transcribed by Sonix with the best speech-to-text algorithms. This transcript may contain errors.

Emmanuel:
Bonjour à tous, bienvenue pour cette nouvelle édition de Tech Ethic Podcasts, qu'on a lancé il y a plusieurs semaines, plusieurs mois maintenant. Pour rappel, le but de ce Podcasts, c'est d'avoir deux émissions par thématique, une émission plutôt pas du tout technique et une émission où on invite un expert de l'IT durant lequel on va essayer de répondre aux problématiques présentées lors de la première émission. Donc, on a eu une émission sur l'accessibilité Web. On a eu une mission sur l'accessibilité des applications natives et avec l'épisode que nous avons enregistré avec Héloïse Dano il y a plusieurs semaines, le sujet d'aujourd'hui est lié au green IT. Merci de partager et faire un peu de pub sur le podcast, ça nous aiderait, à nous faire des feedback aussi pour savoir ce qu'on peut améliorer, ce que l'on peut ajouter, ce que l'on peut supprimer. On est preneur de tout. Et donc, aujourd'hui, je reçois Jérôme Moly. Bonjour Jérôme.

Jérôme:
Bonjour

Emmanuel:
Tu vas bien ?

Jérôme:
Ça va, ça va, ça va.

Emmanuel:
Merci d'avoir accepté l'invitation. On se connaissait de loin sur les Slacks, du CNumr. Je me suis dis tiens, je n'ai pas encore eu l'occasion de parler avec Jérôme, ce serait le bon moment de l'inviter à un Podcasts et de parler Green IT. Est ce que j'ai bien fait?

Jérôme:
Complement !

Emmanuel:
Est ce que tu peux te présenter un petit peu pour ceux qui ne connaitrait peut-être pas ?

Jérôme:
Oui, alors en très rapide. Moi, je suis maintenant expert indépendant en numérique responsable et j'ai un parcours presque classique de développeur. Je suis ingénieur en informatique et je suis entré en ESN. J'ai fait développeurs, chefs de projet, architectes, etc. Etc. Jusqu'à technico commercial et en 2018, j'ai commencé à me rendre compte qu'il y avait des trucs qui tournaient plus tellement rond entre ce que l'on a proposait et puis ce que je ressentais. J'avais décidé de quitter ma boite sans savoir trop quoi faire. Et c'est juste à ce moment là qu'est sorti le premier rapport du Shift sur l'impact environnemental du numérique. Je l'ai lu, j'ai pris une grosse grosse claque et du coup, je me suis dit OK, c'est ça que je veux faire. En tout cas, c'est faire en sorte que le numérique n'ait pas l'impact qu'il a aujourd'hui. Et donc, du coup, de fil en aiguille, je me suis renseigné, puis formé, puisse certifié sur tout ce qui est éco-conception, etc. Et maintenant, j'accompagne des organisations soit en sensibilisation autour de cette thématique là, soit en transformation. Comment on fait ? Soit en réalisation : de dire OK, on veut refaire un produit en l'éco concevant, on veut refaire notre site en l'éco concevant. Qu'est ce qu'on fait ? Comment on fait ? Etc.

Emmanuel:
Tu as parlé de certification et de formation? Est ce que tu peux en citer quelques unes, peut-être pour nos auditeurs ou novices ?

Jérôme:
Alors moi, j'ai fait la formation Green IT à l'époque de greenIT.fr. C'est Frédéric Bordage, qui m'avait fait la formation et ça s'appelait à l'époque : "éco conception de services numériques"

Emmanuel:
Je crois qu'il y a deux formations

Jérôme:
Ah oué, c'était Éco conception web. Oui, et maintenant, je crois qu'il y a deux formations. Il y en a une plus généraliste et une plus orientée mise en oeuvre, il me semble.

Emmanuel:
C'est ça, il y a une formation de GreenIT, où là on parle des impacts du numérique de manière globale. Et celle là, je l'ai fait et il y en a une plutôt orientée bonnes pratiques d'éco conception de services numériques plus dédiée au monde du développement. De ce que j'ai pu comprendre. Très bien, alors si je te dis : "Impact du numérique en 2021" à quoi cela te fait penser?

Jérôme:
Ça me fait penser qu'on est toujours sur la même pente, malheureusement, et qui ne va pas trop dans le bon sens pour l'instant. Pour l'instant, c'est toujours la foire au toujours plus. C'est assez déprimant. À ce qui est hyper inquiétant, c'est la multiplication du nombre d'appareils, ce qui est notamment iOT de près ou de loin. Voilà on a des montres, des pèses personnes connectés, on a à peu près n'importe quel objet aujourd'hui, on a sa version connectée. Comme des carafes connectées, c'est assez ouf...

Emmanuel:
Puisque l'impact principal du numérique, c'est la fabrication des terminaux.

Jérôme:
Aujourd'hui, quand on regarde tous les grands chiffres et qu'on regarde l'impact global, pas que l'impact énergétique, puisqu'il faut vraiment regarder toutes les sources d'impact, c'est vraiment la fabrication des terminaux et en particulier la fabrication des terminaux utilisateurs, donc plutôt la partie grand public de l'informatique. Pas les PC des développeurs, pas les serveurs. Ça impacte. C'est assez anecdotique quand on regarde le grand tout, c'est vraiment côté utilisateur qui a le plus d'impact. Du coup, du coup, en face de ça, l'urgence absolue, c'est de réduire la fabrication de terminaux. Et pour faire ça, il n'y a pas 36 solutions. C'est d'acheter le moins possible de terminaux neufs. Et donc faire durer ceux qui existent autant que possible et éviter la multiplication. Comme je disais, voilà, il y a des milliards d'objets connectés qui, aujourd'hui, peuvent pour certains être presque un terminal. Aujourd'hui, quand on voit un frigo connecté avec un écran de 15 pouces collé dessus, en plus de l'impact du frigo, ça a le même impact qu'une tablette ou qu'un PC avec un écran de 15 pouces. Et donc, il faut absolument, absolument, absolument éviter ces petits gadgets ultra spécialisés qui, en plus en général, ne servent qu'à un usage. Parce que ce qu'il y a sur mon frigo, je ne pense pas que je pourrais l'utiliser pour aller faire un Excel. Et donc, pour les terminaux les plus communs, à savoir PC, smartphone, etc. Ben ouais, acheter le moins possible, acheter le moins possible neuf.

Emmanuel:
Parce que je crois que tu dans une étude du GreenIT.fr, mais à mon avis il doit y avoir la même chose sur le Shift Project, l'impact principal que ce soit en émissions de gaz à effet de serre, en utilisation de ressources non renouvelables ou en consommation d'eau et en consommation d'énergie, le plus coûteux, c'est le terminal utilisateur, non? Pour y arriver, il faut réduire de manière global.

Jérôme:
C'est ça.

Emmanuel:
C'est la conclusion du podcast. Bonne journée au revoir. (rire)

Jérôme:
C'est exactement ça. Voilà, on a fini.

Emmanuel:
Il y a bien un travail de éduquer les gens qui ne connaissent pas l'impact de l'achat d'un device supplémentaire. Il faut travailler sur l'obsolescence, comme disait Héloïse, l'obsolescence sociétale, l'obsolescence de marketing, l'obsolescence technique des appareils qu'on achète et qu'on nous invite à renouveler souvent. Et il faut aussi travailler nous en tant que développeur, même si on n'est pas le seul développeur de l'ensemble des applications utilisées par mon utilisateur lambda. Moi, en tant que développeur, je dois faire le maximum pour que mon application soit fonctionnelle, quel que soit le device utilisé, que ça soit un vieux téléphone ou bien un téléphone récent. C'est bien ça ?

Jérôme:
C'est ça. Et du coup, c'est vrai que on a, on a souvent cette remarque qu'en disant oui, mais moi j'y peux rien avec mon appli parce que de toute façon, Facebook. Parce que de toute façon, Instagram, etc. Oui, mais, si on commence pas quelque part et si on ne fait pas comme dans beaucoup de gestes écologiques, si chacun fait pas sa part à son niveau? Ah ben là, la seule certitude qu'on a, c'est que ça n'avancera pas. Avançons sur ce qu'on maîtrise et donc en tant que développeur : "Oui, OK, Facebook c'est Facebook, Instagram c'est Instagram"... Moi, en tant que développeur sur mon application, je peux agir et je peux agir. Si je peux agir, j'agis.

Emmanuel:
C'est sûr. Je crois que Héloïse avait sorti une expression je ne l'ai plus complètement en tête. "Je ne fais rien parce que le voisin fait pire que moi". Moi j'appelle ça la patate chaude, on se balance la patate chaude pour dire "Ah non, moi je fais moins pire que mon voisin. Si lui, il fait quelque chose, peut être qu'après, je bougerais un petit peu mes fesses". C'est sur que si personne ne fait rien, ça ne peut pas s'améliorer.

Jérôme:
C'est ça. Et puis, il y a aussi une course. On parle aussi souvent des impacts concurrentiels, de ne pas être écolo. C'est quelque chose qui revient souvent. Et en gros, on dit oui, mais si j'essaye d'éco, concevoir, etc. Etc. C'est plus de boulot pour le même résultat en terme de business. Et du coup, et du coup, mon voisin qui lui n'est absolument pas vertueux, ça va lui coûter moins cher, donc il va être plus compétitif, donc il va me manger. Et on retrouve souvent cette réflexion là. Et ce qu'il faut voir, c'est quand on est déjà arrivé à tout un tas de bénéfices à l'éco conception, notamment pour les sites Web. C'est mieux en SEO, c'est mieux en performance, etc. Etc. Il y a des avantages pour l'utilisateur final à utiliser un site éco conçu ou une application éco conçue. Et puis ce qu'il faut voir, c'est qu'il y a aussi, alors pas encore dans le milieu de l'IT, malheureusement, mais dans d'autres milieux, on commence à avoir des comparatifs, des éco score, etc. Etc. Ou des applications typiquement moi une que j'adore c'est Yuka qui permet de savoir si on a des cochonneries dans les produits qu'on achète, etc. Et en fait, j'ai appris récemment que aujourd'hui ça arrivait à avoir des impacts sur des gros industriels de la cosmétique qui ont des notes vraiment pas belle dans Yuka. Qui, du coup remettent en cause tout leur système de fonctionnement parce que ils ont des mauvaises notes sur Yuka. Et j'espère qu'un jour on aura un Yuka dans l'IT. Et là, il y aura des vraies injonctions concurrentielles en disant : Entre une appli verte et une appli pas verte, entre un site vert et un site pas vert, si l'utilisateur a vraiment la capacité de comparer, il se trouve que souvent, il va vers l'alternative la plus verte.

Emmanuel:
Et je rebondis sur ce que tu viens de dire concernant la concurrence entre deux projets l'un qui souhaite bien faire, l'autre qui s'en moque et donc pour lequel le coût de revient serait moins important. Mais le même principe pour les amendes sur les sites qui ne sont pas accessibles aux personnes ayant des déficiences. Ils ont une amende de 20 000 euros par an et par site non-conforme. 20000 euros pour une boite qui fait plus de 250 millions de chiffre d'affaires. La question qu'on m'a posé, c'est "OK. Combien ça me coûte en termes de jours homme pour convertir mon site pour qu'il soit accessible? OK, ça me revient plus cher que l'amende. Je préfère prendre l'amende." C'est comme quand tu payes pas le parking, tu te dis "Je ne pais pas de parking. Au bout d'un moment j'aurais une amende ou mais ça me paiera tous les parkings que j'ai pas payé".

Jérôme:
C'est vrai qu'aujourd'hui, pour l'instant, c'est encore trop peu contraignant. Par contre, le truc vachement positif, c'est que ça bouge quand même lentement, mais ça bouge. Il commence à y avoir des cadres législatifs, que ce soit en France, que ce soit en Europe. Alors pour l'instant, il n'y a pas d'amende si on n'a pas éco conçu son site. Mais bon, on peut penser que de toute façon, vu qu'aujourd'hui, on n'en fait pas assez. Demain, il faudra en faire plus. Demain, les cadres vont se resserrer. Je ne vois pas comment ça pourrait en être autrement. Au bout d'un moment, c'est comme les amendes d'accessibilité, si c'était exponentiel ou si on prenait un malus à chaque fois où, etc. Et que ce soit pas 20.000 euros, mais que ce soit 20.000 euros pour le premier, 40.000 euros pour le second et 80.000 euros pour le troisième. Bon, là, ce serait probablement beaucoup plus facile à respecter.

Emmanuel:
Tu parlais de législation qui n'y avait pas énormément en France et en Europe. Ça veut dire qu'il y en a un petit peu.

Jérôme:
Il y en a un peu. Je n'ai pas encore eu le temps de tout dépouiller les textes, mais il y a des lois qui sont passées. Pour l'économie circulaire, non c'est pas ça, j'ai perdu le nom désolé.

Emmanuel:
J'ai un trou de mémoire aussi.

Jérôme:
Mais qui est sorti il y a quelques jours. Et puis ensuite, il y a des directives européennes au niveau de l'économie circulaire, etc. Etc. Et on commence à voir, même si c'est pas des cadres contraignants, mais on commence à voir une intention de calmer un peu le jeu sur l'obsolescence, de calmer un peu le jeu sur les incitations à la consommation à outrance, etc. Etc. Donc, c'est pas encore ça, mais ça, on va dire les graines sont semées. Maintenant, à nous de faire en sorte que ces textes là soient déjà appliqués en l'état. Et puis, pousser à ce qu'on aille encore plus loin.

Emmanuel:
Le nom de la loi qui est à l'Assemblée nationale, je ne suis pas un expert législatif, mais je sais que c'est passé par le Sénat, c'est passé par l'Assemblée nationale la semaine dernière. Je ne sais plus où on en est là. Mais c'est la proposition de loi visant à réduire l'empreinte environnementale du numérique en France de Patrick Chaize. Je pense que ça doit être ça.

Jérôme:
Oui, c'est ça. C'est la loi. C'est ça, le texte REEM.

Emmanuel:
Très bien donc à suivre. Je t'avoue que j'ai pas trop suivi non plus. Mais en tout cas, il y a un début de loi.

Jérôme:
Voilà ça, ça vient juste d'être fait et du coup justement, on attend impatiemment tous les débriefs des différents acteurs pour se positionner en disant "Ah ben ça, c'est bien, ça c'est un peu léger, ça, ou peut aller plus loin", etc.

Emmanuel:
Affaire à suivre. Alors moi, je te rejoins sur le côté où éco concevoir un service numérique, ça ne peut qu'avoir des bénéfices sur plusieurs critères. Ça peut avoir des points positifs sur l'accessibilité Web( ça je le place à chaque fois). Mais ça peut avoir un impact positif sur la maintenabilité du code. Je pense que si on a moins de fonctionnalités qui ne servent à rien mathématiquement, potentiellement moins de bugs. En termes de performances, en termes de référencement. De manière générale, je veux dire que c'est de la logique, des bonnes pratiques de éco-concevoir un site numérique, Mais en tout cas, le fait d'avoir cette idée en tête d'éco conception ça peut avoir que des effets positifs sur l'ensemble des métriques qu'on pourrait suivre sur un service Web. C'est mon point de vue et je pense que c'est assez logique. Si j'ai un site beaucoup plus simple, avec tout le nécessaire qui est demandé par mes clients, par les utilisateurs, ça ne peut être que positif. Et donc l'éco conception, comment ça marche ? Et à quel moment dans le cycle d'un projet, on doit y réfléchir ? À la fin, à l'arrache, comme beaucoup de choses, ou en amont ? Je pense que j'ai mon idée.

Jérôme:
C'est ça, je pense qu'il y a une partie de la réponse dans la question. Déjà, dans "éco conception" il y conception, donc, on se doute que c'est à la conception que beaucoup de choses vont se passer. En fait, il y a pour moi, il y a vraiment trois grands moments. C'est la conception fonctionnelle, la conception technique, et ensuite, il y a tout ce qui relève de l'optimisation. Les trois sont presque dans l'ordre en termes d'impact. La conception fonctionnelle on aura plus d'impact en cherchant à éco concevoir, au moment de la conception fonctionnelle qu'on en aura au moment de la conception technique, qu'on en aura au moment de l'optimisation. Et justement, les leviers en terme de conception fonctionnelle sont beaucoup plus puissants. Les leviers en conception technique sont un peu moins puissants. Et en termes d'optimisation, ça porte bien son nom, on fait des optimisations. On va mettre un petit coup de tournevis à droite, à gauche, mais c'est pas ça qui va changer la face du monde.

Emmanuel:
C'est très clair. Donc le plus gros de l'impact, si, si on souhaite mettre toutes les billes dans le même panier c'est de travailler en amont au niveau de la phase de conception fonctionnelle ?

Jérôme:
C'est ça. Après si on rentre un peu dans le détail des trois phases, la première, la conception fonctionnelle, on va parler déjà des fonctionnalités. Pour faire simple, c'est comme pour beaucoup de choses. La meilleure fonctionnalité en termes d'impact écologique, c'est celle qui n'existe pas parce que, du coup, elle a besoin de zéro ressource pour fonctionner. Et donc, au moment de la conception fonctionnelle, déjà, c'est le moment où on va challenger le fonctionnel de l'applicatif. Le fonctionnement du service, le fonctionnement du site web et de se poser la question pour chaque chaque fonctionnalité, qu'elle soit grosse ou petite. Est ce que j'ai vraiment besoin de ça et que j'ai vraiment besoin de ça avec un tel niveau de complexité ? Parce que souvent, c'est là où on a tendance à être, comme on dit, à être un peu gourmand. C'est de se dire voilà, je vais prendre des exemples totalement bateaux, mais c'est de dire "OK. Il faut que j'affiche une grille sur ma page web avec un tableau avec des chiffres très bien". On va avoir tendance fonctionnellement à dire "Ah oui. Alors le tableau, il faut trier. Il faut pouvoir trier. Il faut pouvoir filtrer. Il faut pouvoir machin pour pouvoir trucs". Parce que parce ça coûte une ligne dans le cahier des charges ou dans la spécification. Et par contre, c'est là où on se retrouve avec ce qui aurait pu être un bête petit tableau et on n'en parle plus, on se retrouve à avoir, par exemple sur une page web un tableau où je vais injecter du JavaScript parce qu'il faut pouvoir trier, filtrer, etc. Et mon tableau va doubler, tripler, décupler de volume. Parce que j'ai demandé, des fonctionnalités supplémentaires. Et en fait, souvent, on les rajoute de soi même en se disant ça va être plus cool, ça va être plus sympa, etc. Alors qu'on n'en a pas besoin. Et cette notion de besoin est vraiment importante. Il ya des cas où je peux tout à fait admettre qu'un tableau on ait besoin de filtrer, trier, etc. Mais pas sur tous, pas tout le temps, pas systématiquement. Et c'est là où vraiment il y a une espèce de gymnastique. Oui, j'ai 12 tableaux à mettre dans mon appli. Est ce que j'en ai 11 où je peux mettre des tableaux tout simples, et puis un deuxième qui est vraiment hyper compliqué, etc. Est ce que vraiment, je dois mettre du coup toutes les fonctionnalités pour tous les tableaux? Est ce que je dois me limiter juste pour celui là? Parce que je sais qu'il est compliqué et je sais que mes utilisateurs en ont besoin. Parce que sinon, ça serait des fonctionnalités non utilisées. Donc, en gros, c'est comme si dans votre voiture, je sais pas, vous vous chargez 200 kilos dans le coffre d'outils de machin de truc en disant De toute façon, j'ai un coffre. Autant m'en servir. Ben oui, mais si j'ai 200 kilos de matériel dans le coffre que je n'utilise pas, ma voiture va consommer plus, etc. Etc. Dans le numérique, c'est un peu pareil. Sauf que, comme on le voit pas, c'est moins tangible, moins évident. On a tendance à remplir le coffre sans même y penser.

Emmanuel:
Et puis, il y a un pourcentage du nombre de fonctionnalités jamais utilisées par les utilisateurs finaux.

Jérôme:
Oui je ne l'ai plus en tête mais c'est énorme. C'est vraiment quelque chose de l'ordre la moitié des fonctionnalités sont quasiment jamais utilisées.

Emmanuel:
En fait c'est les équipes projets, je met tout le monde dans le même panier : Un développeur, un product manager, tout le monde ajoute des fonctionnalités en pensant créer le meilleur des projets pour se différencier du concurrent. Il rajoute énormément de fonctionnalité qui sont en fait jamais utilisées par les utilisateurs finaux. Et comme le disait Jérome, plus on ajoute des fonctionnalités, plus on a besoin de code JavaScript, plus il y a de ressources statiques à télécharger, plus il y a du code JavaScript à exécuter du côté du navigateur. Et c'est peut être cette exécution intempestive de code Javascript du côté du navigateur qui donne l'impression à l'utilisateur final que leurs terminaux commencent à ramer. C'est pour ça qu'il faut faire attention. Donc, comment tu limites les fonctionnalités nécessaires ? Tu fais des ateliers avec les utilisateurs? des personas?

Jérôme:
C'est essentiellement là, c'est à dire la conception fonctionnelle. Ça dépend des équipes. Des fois certaines font la conception fonctionnelle elles mêmes. Des fois, c'est les designers, les ergonomes qui s'en occupent. Mais en tout cas, clairement c'est demander aux utilisateurs de quoi ils ont besoin. Et après, c'est plus une histoire de posture. En gros, en demandant plutôt ce qu'on peut simplifier ou en essayant de partir de base sur la solution simple et ensuite, dans quelques cas précis, de complexifier un peu la chose plutôt que l'inverse. En fait, c'est surtout ça. C'est vraiment une position où on a tendance, et je l'ai vécu moi aussi, on a tendance à ne pas poser la question et à dire par défaut, je vais lui mettre le gros truc comme ça, je suis sûr d'être tranquille. Et puis se rendre compte que finalement, ce n'est pas utilisé. Alors en tant que développeur on se dit "OK, ma fonction n'est pas utilisée. C'est pas grave". Mais c'est surtout le poids de cette fonction qui n'est pas utilisée et qui sera chargée à chaque chargement de pages et qui sera chargée à chaque fois que l'utilisateur va sur l'application. Voilà il y a un poids. J'ai mis un outil qui ne servira à rien dans le coffre de mon application. Et chaque fois qu'on s'en servira, il y aura le poids de cet outil.

Emmanuel:
Et qui en découle des sites qui font 20 Mo de ressources statiques. Sachant qu'à l'époque on faisait des sites à quelques kilo octet. Là, la moyenne de moyenne, c'est 4 Mo de mémoire. Mais il y a des sites que j'ai déjà audités qui font 12, 20 Mega sans problème.

Jérôme:
C'est ça, et malheureusement aujourd'hui, quand on voit ces sites à 12, 15, 20, Mega... On est plus comme il y a quelques années où c'était : il y a une image gigantesque parce qu'ils ont oublié d'alléger l'image, etc. On a une image qui fait 10 mégas. Et puis on se rend compte que et c'est bon. On allège l'image. Problème résolu. Là, c'est vraiment des petits bouts de gras partout. Et du coup, ça devient plus difficile à éliminer en plus.

Emmanuel:
On a parlé de conception fonctionnelle. Est ce que tu souhaites ajouter des choses sur la conception techniques ?

Jérôme:
Sur la conception technique : Il y a le choix des stack techniques, donc ça, c'est pareil. On n'a pas toujours la possibilité de challenger ces choix là. Des fois, notre client, notre utilisateur, il va dire "Notre site sera fait en telle technologie parce que parce que c'est comme ça, parce que tout marche comme ça chez nous, et la question ne se pose pas". Par contre un défaut, et ça c'est clairement un défaut de technicien on aime bien les nouvelles stacks, les nouveaux outils, etc. C'est beau, ça brille, on a été voir les démos, ça a l'air génial et tout. Sauf que souvent, malheureusement, les nouvelles stack, elles, ont un peu les mêmes défauts que l'industrie dans sa globalité, c'est à dire elles deviennent de plus en plus lourdes parce qu'elles font de plus en plus de choses automatiquement ou semi-automatiquement, etc. Et par contre, elle pèse, elle pèse lourd. Donc, il faut vraiment se poser la question de si je dois aller sur une nouvelle stack technique, etc. Est ce que j'ai vraiment un besoin? Est ce que c'est vraiment indispensable? Les nouvelles fonctionnalités et les nouvelles facilités que vont offrir ces nouveaux outils? Parce que en général, ces nouveaux outils ils sont plus lourd et on revient au problème d'avant. C'est à dire? Les outils sont plus lourds. J'embarque des outils plus lourds. Ça va avoir besoin de plus de plus de tout pour les faire marcher.

Emmanuel:
Après il faut aussi prendre en compte l'impact, mais aussi la vélocité. Il faut un juste milieu. On demande pas de revenir à écrire du javascript à la main pour avoir une application d'édition de documents, mais avoir un juste milieu, en tout cas.

Jérôme:
C'est ça.

Emmanuel:
En connaissance de cause, choisir le framework, en sachant qu'il y a des problématiques d'impact, essayer de comprendre comment réduire ce genre de choses.

Jérôme:
C'est ça. Et d'une manière générale, de toute façon, quand on fait de l'éco conception, le site parfaitement éco conçu, il est extrêmement difficile à trouver. Et c'est vraiment une question d'équilibre. On doit se balader entre tout un tas de balances qu'on doit faire peser d'un côté ou de l'autre. Il va y avoir la balance de se dire voilà, est ce que je vais vraiment dans de l'éco conçu entre guillemets extrêmes? Est ce que je vais vraiment dans du pas du tout éco conçu. En terme de poids? Qu'est ce que je peux me permettre? Où est ce que je peux mettre le curseur pour que ce soit pertinent? Les stacks technique où est ce que je dois mettre le curseur pour que ce soit pertinent aussi? Est ce que j'en ai besoin? Est-ce que j'en ai pas besoin? Quelles sont mes contraintes? Et puis voilà, il y a des contraintes de vélocité. Il y a des contraintes de délai. Il y a des contraintes de compétence. Il y a tout un tas de choses qui fait qu'on a des contraintes et on doit faire avec. La solution, elle, est jamais forcément évidente. Si la solution était évidente, tout le monde le ferait. Donc, et c'est un des motto en éco conception, c'est que ça, ça coûte du jus de cerveau. Vraiment il faut se poser plein, plein, plein de questions. Il faut réfléchir dans tous les sens. À quoi? Comment est ce que je pourrais faire pareil avec moins, voire mieux avec moins? Comment est ce que je pourrais faire pour ne pas utiliser la dernière tech à la mode? Comment est ce que je pourrais faire pour que cette fonctionnalité qui a l'air ultra compliquée, est ce que je ne pourrais pas faire quelque chose de beaucoup plus simple? Je me pose des questions et paradoxalement, moi, c'est ce que j'aime bien dans l'éco conception, c'est que du coup, on se pose plein de questions. Du coup on reprend un rôle. On fait de l'ingénierie, on a plein de contraintes. Il faut trouver des solutions dans ces contraintes. Des solutions plus élégantes, plus sympa. Et du coup, je trouve qu'on revient sur les fondamentaux du code que des fois, on a un peu perdu parce que parce que c'est des nouveaux outils, "clic clic clic clic clic" et c'est tout. Et c'est vraiment moi, en tout cas intellectuellement en développement, je trouve ça beaucoup, beaucoup plus stimulant.

Emmanuel:
Tu disais grâce ou parce que l'on souhaite faire de l'éco conception, on se pose la question. Mais moi, ce que j'ai pu ressentir chez les clients, c'est que pour des raisons de timing, pour des raisons d'agilité, tout ça, on se pose pas de questions. On "ship de la feature". On fait notre pull request, il y a un semblant de revue de code qui est fait. Et bim, la feature elle est testé par le P.O et puis basta quoi. On a malheureusement, dans le fonctionnement actuel des choses, on prend pas le temps de se poser les questions tout le temps. Alors Est ce que ces problématiques d'impact, d'optimisation, etc, est ce que ça devrait être dans la "Definition of Done" dans une tâche agile? Dire une tâche est terminée si et seulement si y eu une revue qui a été faite par un collègue dans lequel il prend en compte. "Ah ! Tu fais ça? Est ce que c'est vraiment nécessaire? Est ce que tu pourrais pas faire autrement pour en réduire l'impact sur ce genre de choses?" Je pense que malheureusement, on ne prend pas l'habitude de poser les bonnes questions au bon moment.

Jérôme:
Oui, je suis entièrement d'accord. Et en plus, on vit dans le milieu des ESN ou des éditeurs de logiciels où comme tu dis, il faut shiper de la feature, de la feature et du coup, c'est extrêmement difficile. Quand le train est lancé à 100 km heure de dire "Oui, mais attendez, je voudrais sauter de côté parce que je pense qu'on peut faire mieux." Mais non, il faut ship la facture et ça peut être assez frustrant.

Emmanuel:
Puisqu'il faut aussi faire de la veille pour savoir comment on pourrait faire autrement. Les plus grosses problématique que je rencontre, qui sont liés à la conception technique que nous abordons maintenant ou à l'accessibilité Web. C'est une méconnaissance des standards de manière générale. Une méconnaissance des standards Web. Si on se limite qu'au Web, les gens, ils savent utiliser le Web, mais ils ne sont pas experts dedans. Ils savent pas le sémantique du code HTML, du code JavaScript. Donc, dès qu'ils veulent faire une fonctionnalité, dès qu'ils ont besoin de quelque chose, ils installent une dépendance supplémentaire qui, premièrement, n'est pas optimisée. Deuxièmement, n'est pas nécessaire parce qu'on a le même fonctionnalités nativement dans le langage. C'est quelque chose que j'ai déjà vu. C'est tout d'abord une méconnaissance des standards Web et ça pourrait résoudre pas mal de problématiques. Je trouve.

Jérôme:
C'est sûr que oui et d'ailleurs, c'est une des bonnes pratiques d'écoconception aussi utiliser les standards, ça veut dire éviter tout un tas de transformations de glue codes, etc. On utilise les standard. On a de grandes chances que tout le monde utilise le standard. Ça se perd un peu, mais oui, si on peut, on prend un standard si il existe. En plus, quand on fait un standard en général des gens qui font des standards, ils ont très, très, très fortement réfléchi au Standard. Donc ils ont pas juste jeté ça sur un coin de table. Quand on voit, quand on voit les RFC. Si vous avez déjà lu une RFC, c'est pas ultra marrant. On sent que les gens se sont vraiment cassé la tête pour essayer de sortir quelque chose qui répond à tous les cas et du coup, se dire "Ah bah non standard poubelle. Moi, je fais un mon truc dans mon coin, ce sera mieux !" En général, au bout d'un moment on le regrette. Et alors là on se rend compte que finalement, là c'est du vécu projet, vu tout ce que l'on a rajouté, on n'est plus très loin du Standard, donc on va tous migrer pour finalement utiliser le standard qu'on a soigneusement évité dès le début. Et c'est du vécu ça. Ça nous avait un peu piqué l'équipe projet. Ça nous avait un peu piqué le jour où, finalement, le truc qu'on avait tous décidé de refuser obstinément, on a dû passer dessus la queue basse.

Emmanuel:
Et les joies du projet. Nos conseils pour les développeurs ou développeuses qui nous écoutent. Intéressez vous au Standard, quel qu'il soit dans votre milieu de compétence, que ce soit web ou autre. Plus vous rapprocher des standards, mieux ce sera pour la vie du projet et pour les performances du projet et pour l'accessibilité du projet. Grosso modo, ça peut aider.

Jérôme:
Les gens qui le reprendront derrière vous. Accessoirement, ça vous évitera d'écrire de la doc puisque le standard, la doc en général, on n'aime pas écrire de la doc. Quand elle est déjà faite. C'est quand même vachement pratique.

Emmanuel:
Moi, je prends l'exemple souvent à chaque projet front que j'audite, j'ouvre un fichier et 95% des cas où il y a les mêmes problématiques. Dans un projet Web, on a un package.json qui est àà où on définit les dépendances du projet. Ce premier fichier que j'ouvre et souvent je vois les dépendances de "Moment.js" pour la gestion des dates et Lodash pour apporter des fonctions utilitaires pour les tableaux. Déjà ça, tu sais qu'il y a un gros travail à faire. Pourquoi puisque premièrement, Moment n'est plus maintenu. Deuxièmement, parce que si tu fais pas gaffe par défaut, Moment quand tu ship ton projet en prod, il arrive avec toutes les traductions, toutes les formats de date, de toutes les langues, même celles que tu utilises pas. Donc par défaut en prod, dont ton code JavaScript tu auras tout pour formater du Yiddish, de l'espagnol ou n'importe quoi. Et donc, grosso modo, dans tes 20 mégas au moins un quart qui est Moment. Sachant que la plupart du temps, les gens n'ont pas besoin parce qu'on a quelque chose nativement en JavaScript qui permet de le faire. Et même pour Lodash. Les gens installent Lodash pour faire un filter ou map sur un tableau. On a quelques chose de natif depuis des années en JavaScript. Pourquoi vous l'utilisez pas? Et donc, tu vois ces deux briques dans le package.json, tu es sûr que la taille du livrable fait a minima 10 Méga, c'est mathématique.

Jérôme:
C'est exactement ce qu'on disait sur le fait de mettre des outils dans le coffre sans trop savoir pourquoi ni comment. Ça peut toujours servir ça. Et le "ça peut toujours servir", il coûte cher.

Emmanuel:
Donc on a parlé de conception fonctionnelles, conception technique. Est ce que tu veux parler un petit peu des optimisations?

Jérôme:
Je voudrais rajouter un petit point sur la conception technique. Même trois point sur les stratégies. Parce qu'en plus en conception technique, c'est là où, en tant que développeur, on a son mot à dire. Et donc, il y a des stratégies de compatibilité. Bon, heureusement, on a plus des IE6 à supporter. Mais par contre, aujourd'hui, on peut avoir des Android 4 à supporter ou des choses comme ça. C'est à mon sens hyper important parce que si on en vient à ce qu'on se dit en tout début d'émission, il faut absolument éviter de rendre obsolescent le terminal de l'utilisateur qui va utiliser notre app ou notre site et donc supporter les anciens terminaux. Vérifier la compatibilité au mieux avec les anciens terminaux, c'est un truc essentiel. Après, c'est pareil, c'est une balance ou il va falloir trouver un équilibre entre les deux. Mais en tout cas, si on peut se dire je supporte les terminaux d'il y a 4 ans, 6 ans, etc. C'est toujours mieux que de dire je me pose même pas la question. Et dans ce cas là, il y a de fortes chances que tous les terminaux qui ont plus de 18 mois ne seront pas supportés parce que pour une très bonne ou mauvaise raison ou juste parce que je n'ai pas fait attention. Donc, la stratégie de compatibilité, pour moi, c'est vraiment assez essentiel. Et puis, ce qui touche au "mobile first", donc ça, on y vient quand même de plus en plus. Mais c'est vrai que l'approche mobile first et l'éco conception sont très copines. Parce que concevoir son site d'abord pour être utilisé confortablement sur un smartphone, etc. On va se poser justement la question de la légèreté fonctionnelle parce que sur un smartphone on ne peut pas faire autant de choses que sur un PC avec une souris, un écran externe, etc. Et puis, en termes aussi de temps de chargement, de chargement des données, de simplicité graphique, etc. Si on conçoit d'abord pour le smartphone, alors on fait quelque chose de léger assez naturellement. Moi ce que je dis souvent si, si on veut faire de l'éco conception en se posant jamais la question de ce qu'on fait, on prend un vieux smartphone. Donc vous prenez un Galaxy S4 ou S5 qui commence vraiment à dater. Vous allez vous mettre quelque part où vous avez une barre de 3G ou deux barres de 3G, mais pas plus. Et vous utilisez ça pour faire tous vos tests? Et si votre site web, si votre appli, elle marche de manière satisfaisante sur un vieux smartphone avec du réseau pas terrible, vous aurez naturellement implémenté la plupart des bonnes pratiques d'éco conception parce que ça, c'est vraiment ça, c'est vraiment un point essentiel, tout ce qui est stratégie de compatibilité. Et puis, "qu'est ce que je fais si j'ai du mauvais réseau?" Etc. C'est vraiment essentiel. Il y a une autre stratégie qui est importante. C'est tout ce qui est la vie des données. Donc là, les ESN sont relativement maintenant au courant parce qu'il y a eu un truc très désagréable ces dernières années, qui s'appelle la RGPD et qui a fait qu'on a été plus ou moins forcé de se préoccuper du sujet. Et donc, c'est la vie et la mort des données. Qu'est ce que je créé comme données? Quand, quand est ce que je crée ces données? Et puis, quand est ce que je tue ces données? Parce que c'est bien beau d'avoir des bases qui se remplissent toujours plus. Etc. Etc. Mais au bout d'un moment, si c'est pour avoir des téraoctets de trucs qui servent à rien, c'est pas très pertinent. il y a une expression que j'aime bien là dessus que j'ai découvert il y a assez récemment c'est la paperasse numérique : La numéras. Dans l'administration avant on disait "la paperasse, la paperasse". Aujourd'hui, on a quand même facilement tendance à faire de la numéras, c'est à dire "OK, il n'y a plus de papier, mais on crée de la donnée, on crée de la donnée, on crée de la donnée" qui sera pas forcément pertinente. Et un petit dernier point est vraiment rapide c'est sur la troisième stratégie à laquelle il faut bien penser, c'est tout ce qui est upgrade de son logiciel. Et ça, c'est un point, notamment sur les textes réglementaires sur lesquels ça avait pas mal bataillé. À savoir tout ce qui est séparation du correctif et de l'évolutif. Donc, quand on fait un site web, on se pose pas vraiment ce genre de question. Quand on fait des applis, c'est important de se poser la question est ce que je suis capable de séparer mes correction de mes évolutions? Donc, est ce que quelqu'un qui a un terminal un peu ancien, est ce qu'il va pouvoir mettre à jour mon application en terme de sécurité sans rajouter les nouvelles fonctionnalités? Ça, c'est très, très touchy. En général, on est très, très contraint, donc on n'a pas vraiment le choix de faire ou de pas faire. Si on peut faire, parce que clairement, la séparation du correctif et de evolutif, l'obsolescence logicielle et les téléphones qu'on met dans un placard parce qu'on ne peut plus avoir la nouvelle version 2. Parce que ce n'est pas supporté par sa version iOS ou sa version Android ou les autres, c'est là qu'on crée de l'obsolescence. Donc, c'est un point si on a la possibilité de s'en soucier. Il faut s'en soucier. C'est hyper important.

Emmanuel:
Je rebondis sur ce que tu as dis concernant la comptabilité des device en général. On souhaite que l'application soit fonctionnelle sur le plus grand parc de device. Mais on ne dit pas que l'application doit être 100% fonctionnelle de la même façon sur les iPhone 11, ou sur les Galaxy 4. Il faut juste que l'utilisateur soit capable de faire la même chose. Sur les deux devices. C'est peut être avec un beau tablea comme prenez par exemple tout à l'heure Jérôme, un tableau avec des filtres, tout ça sur les téléphones récents et pour les vieux, les vieux téléphone, ça peut-être un tableau dégradé, mais chacun est capable de faire la même chose qui est de visualiser la donnée. C'est très lié à l'accessibilité. L'accessibilité ce n'est pas que pour les personnes, les personnes ayant des déficiences visuelles, cognitives ... C'est juste rendre un service numérique accessible à tout le monde, quel que soit son contexte d'utilisation. Une personne ayant une déficience ou pas, étant dans un désert numérique ou pas, ayant un vieux téléphone ou pas. De manière générale, c'est rendre accessible de manière X ou Y un service numérique dégradé ou pas. Mais en tout cas, être capable de faire la même chose.

Jérôme:
C'est ça. Et moi quelque chose que j'aime bien, mais qu'on voit de moins en moins. C'est la version light des sites qui, des fois, sont hyper agréables. On prend plus de plaisir à naviguer sur la version light parce "on clique ça marche, on clique ça marche". Plutôt que de cliquer sur la version classique entre guillemets où il faut attendre que ça change, etc. Etc.

Emmanuel:
L'autre terme que tu as employé "mobile first", pour les auditeurs auditrices, j'emploie le terme de "progressive enhancement". C'est que je fais la version light et j'active des fonctionnalités en fonction des contextes d'utilisation, en fonction du réseau, en fonction du device, en fonction de la taille de l'écran, etc. Comme disait Jérôme, on pars, pas du pire, Ce n'est pas le pire, mais du contexte le moins optimal. Et ensuite, on active des fonctions supplémentaires si nécessaire, seulement si nécessaire.

Jérôme:
Et si nécessaire. Si le terminal sait faire mieux, c'est de dire " De base, je te propose ça. Si, par hasard, tu sais faire mieux et que tu as la possibilité, en termes de réseau de fonctionnalités extérieures, de faire mieux, alors je te propose, je te propose mieux, plus confortable", etc. Et ça, clairement, c'est hyper intéressant. Et d'ailleurs, il y a quelques features de Chrome très récentes qui commencent à aborder ces notions là. Alors j'ai perdu le nom du flag dans Chrome qui dit en gros "je suis en mode bande passante limitée" ou quelque chose comme ça.

Emmanuel:
C'est une méga query qui s'appelle "Preferes reduced data".Tu peux mettre soit dans le HTML, CSS, en JavaScript et c'est à l'utilisateur dans ces settings, je pense global à son OS. Qui peut dire je préfère optimiser la bande passante. Et donc, vous, en tant que développeur, vous pouvez utiliser cette information là pour charger ou pas des ressources statiques, donc charger des images moins volumineusespar rapport à d'autres, etc.

Jérôme:
C'est ça. Et du coup, la bonne pratique, ce serait de dire en gros, si on n'a pas explicitement défini qu'il ne voulait pas de version allégée, proposer plutôt la version allégée. Et si il a dit non, je ne veux pas la version allégée parce que j'ai un super PC, j'ai la fibre optique, etc. Et qui va bien ticker le flag, "non". À ce moment là, je lui propose toute la panoplie.

Emmanuel:
Parce que souvent, on voit l'inverse dans le code qu'on voit sur Internet. Ils prennent par défaut la valeur comme si je suis je souhaitais ouvrir le robinet à fond quoi. Mais en fait, il faut faire l'inverse, comme tu dis. Par défaut, on dit que le robinet est fermé et seulement si l'utilisateur a explicitement dit "Je veux télécharger des choses" c'est à ce moment là que tu l'active. Et par défaut, tu dis : "Le robinet est fermé". Comme ça les navigateurs qui ne supportent pas encore cette méga query, ils sont utilisés aussi par défaut.

Jérôme:
Ça est d'une manière générale. De toute façon, ça revient à tout ce qu'on se dit depuis, depuis le début. Par défaut, on a préféré la simplicité, la légèreté, etc. Et si, si, explicitement, on vous demande le truc puissant, si explicitement on vous demande le tableau avec les filtres, etc. Alors à ce moment là, OK, on ouvre les robots.

Emmanuel:
Donc, à titre indicatif il y a aussi ce même genre de flags pour activer ou désactiver les animations. On sort un petit peu les sujet, mais les visiteurs peuvent faire le choix de désactiver les animations, en tout cas de dire qu'on préfère les sites avec le strict minimum en termes d'animation. Et donc, vous pouvez utiliser ce même genre de media query pour dire si oui ou non j'active mes animations sur mon site pour faire plaisir à votre utilisateur. Très bien. Tellement de sujets à parler, sur ce domaine là. On pourrait parler pendant deux heures.

Jérôme:
On pourrait y passer la journée.

Emmanuel:
Tu m'as parlé des conceptions techniques. Est ce que tu veux aborder des choses sur l'optimisation?

Jérôme:
Oui alors, l'optimisation, comme son nom l'indique déjà, elle aura des effets relativement marginaux. Quand on dit à ce moment là, c'est comme l'accessibilité d'ailleurs, c'est quand tu posais la question est ce qu'il vaut mieux s'en préoccuper au début du projet, à la fin du projet, si vous vous préoccupez de d'éco conception à la fin du projet, c'est pas gagné. Et donc, en termes d'optimisation, il y a deux, trois choses qui sont à peu près commune à tout logiciel conçu de manière, à de manière professionnelle. C'est le travail sur les algos. Là, c'est pareil. Moi, je les ai vu et vécu, mais j'ai vu des gens qui étaient développeurs depuis des années en société de services ou chez des éditeurs qui ne savent qu'ils ne connaissent plus les algorithmes de base et qui se retrouvent à imbriquer des boucles dans des boucles, dans des boucles et se dire "Ah bah oué mais je ne comprends pas, ça ne marche pas". Mais oui tu as trois boucles les unes dans les autres, tu as un million d'itération sur chaque ligne. Tu feras pas de miracles. Les basiques de l'algorithmique sont extrêmement importants. Et l'autre point, c'est pareil, et là, ça ne dépend pas non plus d'un langage, c'est le design pattern qui sont essentiels. La plupart des problèmes qu'on rencontre en informatique, on peut les rapprocher d'un design pattern. Et ils sont connus, discutés, il y en a encore certains qui sont débattus aujourd'hui, mais en gros, les solutions en termes de design logicielle, ça fait que ça fait 30 ans qu'on utilise les mêmes plus que ça. Et donc, ne pas connaître les design patterns est un bon moyen de faire n'importe quoi. C'est un peu comme les standards. Donc du coup, c'est les deux points. Les algo et les design patterns, pour moi, ça fait partie du package de base du développeur. A priori, il y a des gens qui ne pensent pas, mais moi, ça fait partie des compétences de base et de toute façon, vous verrez dans votre vie professionnelle... J'ai commencé en 2002 ce n'était pas la préhistoire. J'ai changé de langage 7-8-9 fois. Et donc en passe du C++, et puis ensuite, on fait du C. Puis ensuite, on fait du Pascal, puis ensuite on fait du C#. Puis ensuite javaScript. Javascript a une durée de vie relativement importante, par exemple, puisque aujourd'hui, c'est le langage privilégié. Faut bien se dire que il aura aussi sa durée de vie et que vous changerez de langage. Par contre, quel que soit le prochain langage qui sera à la mode dans 50 ou 10 ans, les design patterns et les algos, si vous faites 3 boucles imbriquées les unes dans les autres, ça marchera pas, quel que soit le langage. Donc, si vous savez éviter cela, vous éviterez beaucoup, beaucoup, beaucoup de problèmes. Et puis ensuite, sur les optimisations : Travailler sur l'efficience de son logiciel, mais en gros, justement, quand on fait des mesures de perf et des mesures de charge. Mais regardez vraiment s'il y a des pics significatifs sur les temps de chargement ou des trucs comme ça. Parce que c'est le genre d'à-coup, justement, qui pèse lourd. Ensuite, faire en sorte qu'il soit efficient. Dans le web, il y a tous les outils d'aide à la performance qui sont qui sont là pour ça et qui peuvent vous aider. En général, ce n'est pas une vérité stricte, mais souvent efficience, performance, etc. C'est un peu. On retrouve un peu les mêmes points de blocage. Donc quand on arrive à les lever, on gagne un peu sur tous les tableaux. Et pour ceux qui sont plutôt sur du back, travailler tout ce qui est lissage des charges, c'est à peu près l'équivalent en version back. C'est de se dire est ce que je peux faire des traitements asynchrones? Est ce que je suis obligé de répondre immédiatement à l'utilisateur en faisant une méga requête bases de données, etc qui va mettre de tout le système à genoux pendant 3 secondes? Ou est ce que je peux lui dire "Ah, je vais m'occuper d'aller chercher ta réponse. Je t'en verrai une petite, une petite notification quand j'aurai fini mon calcul". Pourquoi? Parce que nos systèmes ont les dimensions, souvent en fonction du maximum à un instant T. Si du coup, on travaille trop en synchrone, on le voit dans la plupart des entreprises. Le matin quand les gens se connectent à 9 heures, il y a un énorme pic. Il y a des pics d'activité. Plus on travaille en asynchrone, plus on peut lisser la charge, plus on peut avoir un plus petit système de coup parce que la charge sera mieux réparties dans le temps. C'est vraiment les trois gros points sur les optimisations que je vois aujourd'hui. Mais par contre, on voit bien que ça reste quand même avec une portée assez limitée par rapport à tout ce qu'on a pu échanger en début sur la conception fonctionnelle et la conception technique, où là c'est vraiment des grosses choses à aller gagner. Sur l'optimisation, on ne fait que de l'optimisation, même si on peut en faire des jolie, ça reste des optimisations.

Emmanuel:
Et si on n'a pas fait le travail, le travail sur la conception technique, ça sert à rien d'optimiser. Enfin je vais pas dire que ça sert à rien, mais il serait préférable de se poser les questions.

Jérôme:
Alors voilà, ça aura des impacts très, très, très, très marginaux. Et d'ailleurs, c'est pour ça que des fois, quand on voit des gens qui débarquent en disant "oui, on peut concevoir mon site, machin, etc. On va passer, on va faire des optimisations". Ouais, mais bon, oui, si vous avez plein de sous et du temps à perdre pourquoi pas. Mais ce n'est pas vraiment le bon moment.

Emmanuel:
Bien merci. On arrive à la fin de cet enregistrement. Pour conclure, j'ai l'impression de tout ce que l'on s'est raconté pendant une heure là, que c'est quand même assez lié à la qualité logicielle, au Software crafmanship, à s'assurer que dans une équipe donnée, chaque fonctionnalité développée soit validée, soit révisé, soit relu par un collègue, pour mettre un petit tampon pour dire "ce code est de qualité, c'est bon, tu peux mettre en prod". Limite la façon de faire, on l'a déjà parce qu'on fait déjà des revues de code et tout ça, mais il faut juste que les gens aient en tête que il y a pas mal de problématiques qu'on peut vérifier lors de la phase de conception ou de développement pour réduire l'impact du service numérique que l'on développe. Et qu'il faut également sensibiliser l'ensemble des parties prenantes, soit les PO, PM, dev, toutes les parties prenantes d'un projet pour qu'ils connaissent l'impact et pour que tout le monde puisse avoir son mot à dire. Et quand il y a quelque chose qui ne va pas, ne pas hésiter à prendre la parole et dire pourquoi ça ne va pas.

Jérôme:
Complètement d'accord avec ça. Et oui, il y a les méthodes, elles existent. Il n'y a pas une nouvelle méthode d'éco conception, etc. Les méthodes, elles, existent. Il y a l'agilité, où il y a plein d'outils qui peuvent permettre de prendre en compte l'éco conception. Il y a le craftmanship, qui est vraiment là, est totalement en phase avec les principes de l'éco conception. Tout ça, ça existe. Pour moi, c'est des métriques en plus à mesurer, à prendre en compte. Avant, on ne prenait pas en compte parce qu'on n'était pas conscient de tout ça. Maintenant, on peut se donner des métriques. Voilà "est ce que mon code est sobre? Est ce que ma page est légère?" Etc. Etc. Et si on les prend en compte, comme pour l'accessibilité, si on prend en compte dès le début du projet et que à tous les moments, on se pose la petite question "est ce que je suis éco conçu ?" Comme "est ce que je suis accessible?" Comme "Est ce que je suis multilingue?" En fait, il y a plein de petits trucs comme ça ou si on le prend en compte dès le début du projet et qu'on l'intègre dans tous les cycles de review, c'est assez marginal comme effort. Si on le prend à la fin, au dernier moment, comme pour l'accessibilité, comme pour le multi langue, etc. Si on le prend à la fin, malheureusement, ça ne se passe pas très bien.

Emmanuel:
Et ça ne sera pas fait.

Jérôme:
En général, c'est ça qui se passe.

Emmanuel:
Merci beaucoup Jérôme pour cette petite heure ensemble. J'espère que cette émission vous a plu. N'hésitez pas à faire des retours. Je partagerai les liens si vous voulez être en contact avec Jérôme. Si vous voulez lui poser des questions ou n'importe quoi en relation avec le sujet d'aujourd'hui, n'hésitez pas à nous faire des retours par mail, sur les logiciels de Podcasts, sur Twitter, on est preneur de tout. On débute dans le domaine des Podcasts, donc on accepte tout retour positif et négatif. On vous donne rendez vous au prochain épisode. On n'a pas encore le sujet normalement. Au mois de juillet (Note : oui nous sommes en retard), vous allez avoir quelque chose. Bonne journée à vous tous et toutes. A bientôt et merci encore à Jérôme.

Sonix is the world’s most advanced automated transcription, translation, and subtitling platform. Fast, accurate, and affordable.

Automatically convert your mp3 files to text (txt file), Microsoft Word (docx file), and SubRip Subtitle (srt file) in minutes.

Sonix has many features that you'd love including generate automated summaries powered by AI, automated subtitles, share transcripts, secure transcription and file storage, and easily transcribe your Zoom meetings. Try Sonix for free today.