Dans une conférence à deux voix, nous vous proposons une plongée dans une opération de sauvetage du Web actuel.
Comment limiter l'impact de nos applications au quotidien? L'éco-conception c'est bien mignon mais quand on arrive sur un projet qui traine une DB trop lourde pour lui et un legacy tout pourri, il est plus difficile de déterminer par où commencer à faire le ménage.
Ca tombe bien, c'est notre quotidien le ménage d'internet. On aimerait le partager avec vous pendant cette conférence.
Par des exemples concrets, nous évoquerons avec vous les défis liés aux fonctionnalités à (ne pas) développer puis nous vous donnerons des arguments pour orienter les choix d'hébergement et d'architecture pour terminer avec les bonnes pratiques de code (en PHP et Symfony mais pas seulement) que nous transmettons à nos clients. Nous souhaitons tous travailler à construire un web plus propre, voici comment nous avons décidé de nous y atteler dans la coopérative.
_ Bonjour à toutes. Merci d'être venu si nombreux. Merci à l'AFUP de nous permettre de parler de ce sujet. Vous allez avoir des éléments tech. On va peut-être commencer par se présenter. Je suis la maman. J'ai cocréé deux petits garçons et une coopérative avec Monsieur. Ce qui m'intéresse dans mon travail au quotidien, ça va être la dynamique du groupe. Je me suis rendu compte au fur et à mesure que plus les gens étaient fiers du produit, plus c'était facile de les convaincre de travailler ensemble, et plus l'entente était intéressante est bonne.
_ Bonjour à tous. Je suis Mathieu, le papa. Je suis aussi cofondateur de la coopérative Fairness. Je suis développeur en backend avec plus de 10 ans sur du PHP Symfony. Je vais parler des différentes missions que je peux effectuer. Je suis un grand fan de tout ce qui va être DDD et architecture hexagonale. Si vous voulez en parler, n'hésitez pas à venir me voir.
_ Fairness, il y a de plus en plus de coopératives du numérique. Créez-en ! On est tous associés. On est propriétaire de notre outil de travail. On partage les bénéfices à la fin de l'année. Aujourd'hui, on est 7. Il y en a à Lille, à Paris. On sensibilise, en forme nos clients. On va développer des produits avec eux sur l'affinage du besoin utilisateur, jusqu'au développement, avec des critères de qualité et d'éco-conception qui sont de moins en moins négociables. Notre objectif aujourd'hui va être de vous donner envie de nettoyer Internet avec nous. Je vais d'abord vous convaincre qu'il ne devrait plus y avoir de débat, qu'il faut le faire, maintenant. Ensuite, on va vous parler concrètement de ce qu'on fait au quotidien, moi, du côté PO et Mathieu, du côté tech. Sans oublier nos amis du côté mesure. Vu l'ampleur des dégâts qui sont liés au numérique, il faut qu'on y aille. Il y a d'autres secteurs qui sont pires que nous. On n'est pas là pour révolutionner l'histoire des bâtiments. On va parler d'Internet. Aujourd'hui, le numérique, c'est 4 % des émissions de gaz à effet de serre mondiales. Je vous ai mis une slide, un graphe qui vous parle de l'énergie primaire. Ce sont des produits non transformés. Je vais vous parler de pétrole, gaz, charbon. Toutes ses ressources, en plus des métaux que l'on utilise pour créer les terminaux, vont nous permettre de fabriquer le numérique et de le faire fonctionner.
Aujourd'hui, la majeure partie de la pollution liée au numérique, c'est la fabrication des terminaux utilisateurs. On a besoin de ces terminaux pour faire avancer le numérique. Aujourd'hui, Internet, c'est physique. Certes, il y a des data centers, il y en a quelques millions dans le monde. On a des dizaines de milliards d'objets connectés qui sont aujourd'hui à peu près avec une durée de vie de deux ou trois ans si on parle de nos téléphones. On a une grosse problématique liée au fait qu'on ne réussit à les recycler qu'à hauteur de 5 %. Ce n'est rien. Le truc, c'est qu'on ne peut plus se dire que le problème du numérique, c'est les mails. Aujourd'hui, on sait fondamentalement que c'est le fait de changer de terminal de façon régulière, d'avoir la 5G qui fait changer tous les terminaux. Le constat est assez simple. On a qu'une planète viable pour le moment. Elon Musk a sans doute un plan B, mais je n'ai pas encore l'info ! Aujourd'hui, on arrive sur la fin des ressources accessibles pour fabriquer les téléphones et tous les objets numériques. Typiquement, pour fabriquer vos téléphones portables vous écrans tactiles, il y a besoin de verre. Au-dessus, vous rajoutez de l'indium, qui est élément 49 du tableau de Mendeleïev. On extrait les ressources. On estime qu'on est à peu près entre 2 à 5 ans de ressources d'indium disponibles. Ensuite, il faudra qu'on fasse éclater la montagne pour réussir à récupérer de la poussière d'indium.
Nos métiers sont vraiment intimement liés aux ressources minières. Sans ressources, on n'a pas de terminaux, sans terminaux, on n'a pas d'utilisateurs, ni de besoins, ni de PHP. La solution, c'est de réussir à faire en sorte que les terminaux durent le plus longtemps possible. Aujourd'hui, un utilisateur change de téléphone tous les deux ou trois ans. Certes, il y a le marketing, mais il y a aussi notre responsabilité. Aujourd'hui, on ne change pas notre téléphone parce qu'il ne marche plus. Les changes parce qu'ils rament. Ils rament parce que les avancées technologiques des nouveaux devices sont tels que l'on peut avoir des puissances de calcul dingues. Comme on peut faire des choses lourdes, on fait des choses lourdes sans faire gaffe. On essaie de faire les choses les plus légères, pour faire en sorte que nos utilisateurs n'aient pas à changer de device pour utiliser nos services. Le problème, c'est que l'on sait pertinemment que l'on fait charge à nos utilisateurs des choses qui leur sont parfaitement inutiles. Avec les stats de navigation, on sait que 70 % des pages ne sont pas ouvertes. Si on rajoute les fonctionnalités qui sont de temps en temps sollicitées, on arrive à 80 % des applications que l'on développe qui ne sont pas fondamentalement nécessaires. C'est énorme. Mon boulot, ça va être de faire la PO relou, et de demander pourquoi. Un client m'a demandé de faire quelque chose de compliqué. Pourquoi on peut la demander ? C'était un client qui faisait de l'événementiel. C'était vendu en marque blanche.
Ça nous arrivait d'avoir des demandes de nos clients qui venaient de ses autres clients à lui. On me l'a demandé 5 fois l'année dernière. C'était une plateforme qui faisait des milliers de connexions par jour. Ce n'est peut-être pas indispensable. Est-ce qu'on pourrait peut-être mettre un numéro de téléphone pour les questions supplémentaires, comme ça, on répond rapidement aux 5 personnes qui vont se poser la même question l'année prochaine ? Finalement, il a gagné de l'argent. Nous, on a gagné du temps. Et en plus, on a fait économiser des recherches à tous les utilisateurs qui n'auront pas à charger cette application ou cette fonctionnalité qui ne servait à rien. Le gros de mon métier, ça va être d'éliminer tout ce qui ne sert à rien, de l'identifier et de réussir à dropper, de discuter avec les clients pour faire sortir le gras numérique qui alourdit toutes nos applications. Une fois qu'on a identifié ce qui était nécessaire, je continue avec mon rôle de PO relou et je pose des questions sur ce qu'on va garder. Les requêtes qui arrivent sur la page d'accueil, qui partent dans tous les sens, pourquoi ? Les traqueurs que l'on met juste parce qu'on a envie d'en mettre, on ne sait pas quoi faire des données derrière, pourquoi ? On a une augmentation à 311 % du nombre de requêtes en 5 ans. On ne sait pas exactement pourquoi les faire avançaient. Il y a 10 ans, une page moyenne, c'était 500 ko. Aujourd'hui, on arrive à 2 Mo. On se pose ces questions de façon régulière. On se rend compte qu'identifier les problématiques et les résoudre, c'est assez facile, de réussir à identifier les problématiques, de les régler. C'est très satisfaisant de nettoyer Internet. On obtient vite d'énormes gains. Chez Bing, ils ont réfléchi à refaire la page recherche. Ils ont réduit de 20 % le nombre d'éléments chargés par leurs utilisateurs. Économie de la charge serveur ? Un petit chiffre ? 20 % ? Qui dit mieux ? Plus que 50. 80 % d'économie, sur la charge serveur, parce qu'on a supprimé les éléments sur la page. On a très vite un énorme gain si on optimise tout ce qu'on réussit à avoir là-dessus.
_ Un autre chiffre impactant : on a réussi à envoyer des hommes sur la Lune avec quelques kilo-octets en mémoire vive. Aujourd'hui, on n'en aurait pas assez.
_ Une fois que j'ai réussie à optimiser secondaire, il y a de nouvelles fonctionnalités que l'on doit développer. Je demande d'intégrer des UX. Ils réfléchissent aux besoins utilisateurs pour savoir ce que l'utilisateur a vraiment besoin d'avoir sur l'application. Mais ce n'est pas forcément exactement les envies du client. C'est le gap entre les réels besoins. Chez Fairness, on travaille souvent avec les designers éthiques. Autant mettre le paquet sur l'équipe qui va s'en occuper. Plus on a de cerveau autour de la table, plus on a de neurones, meilleur sera le produit. J'intègre l'équipe de développements très en amont des projets. Déjà parce que vous avez des cerveaux, autant s'en servir ! C'est intéressant d'avoir votre retour sur le besoin utilisateur. Et quand on a des évocations, des fonctionnalités intéressantes, on va potentiellement poser des options d'architecture. Le fait d'avoir des informations sur ce que ça va avoir comme impact d'un point de vue technique, on va plutôt faire le choix de ce qui va être le moins gourmand en ressources. Parmi vous, qui a l'impression de récupérer une espèce de cahier des charges et on vous demande juste de développer ce qu'on a décidé de faire ? Et Qui a l'impression d'être intégré sur la réflexion du besoin utilisateur, et qui peut dire que ça ne vous pas paraît pas pertinent ? J'aurais préféré que vous soyez tous à lever la main sur la deuxième solution. Plus on va être nombreux autour de la table, plus on va poser la question de pourquoi, plus on sera sûr qu'on est en train de créer ensemble la meilleure solution.
_ Une fois qu'on a amélioré le produit, le nerf de la guerre, c'est mettre les chiffres. On va manquer de données précises sur l'impact environnemental de nos applications. La première des choses que je fais, c'est que je vais faire un état des lieux pour savoir où je mets les pieds. Ça va me permettre d'avoir une base de recommandations et ça va me permettre de pouvoir faire une comparaison avant et après pour que je puisse constater les biens que l'on n'a pu obtenir. Je vais vous présenter comment on fait pour mesurer tout ça. Il existe des outils qui sont plus focus sur la perf. Je ne vais pas vous les présenter. Ce sont des outils qui ne sont pas focus sur la mesure d'impact environnemental, mais on va pouvoir faire quelques parallèles. Le problème, c'est que ce sont des outils que j'appelle généralistes. Ça va prendre l'entièreté de votre application, backend et frontend. On est des développeurs backend. Ça ne va pas nous donner des indices sur comment je vais pouvoir améliorer mon API et mon backend. Il y a Blackfire et DataDog. Vous les connaissez très certainement. Dans le cadre de Blackfire, ça va vous donner des outils précis sur le temps des exécutions, sur le nombre de requêtes SQL qui vont être exécutées, ça va vous donner une arborescence de combien de fois et comment sont utilisées vos fonctions. Ça va vous permettre d'améliorer vos applications et d'améliorer votre impact environnemental.
_ Il y a d'autres outils qui sont très spécifiquement orientés mesures de l'impact environnemental de vos applications. Chez Fairness, on les utilise tous. Ils ne mesurent pas la même chose. Cette pléthore de chiffres et de notations que l'on récupère vont être analysés, comparés avec les outils techniques pour que l'on puisse avoir un plan d'attaque et un travail qui soit plus pertinent sur les applications des clients. Je vais vous en présenter quelques-uns. Eco-index est basé sur les bonnes pratiques dont on va vous parler derrière. Il y a Greenframe.io, Scaphandre du côté infra. Après, vous en avez d'autres sur la consommation électrique. Il y a Carbonalyser et Greenspector. Tous ces outils sont différents. Ils ne mesurent pas la même chose mais vont être complémentaire. Ne le faites pas sur un seul. Essayez de comprendre quels sont les chiffres qui vont vous être donnés. Essayez de faire tourner plusieurs outils, et ensuite, de les analyser pour avoir quelque chose de pertinent.
_ Tous ces outils sont en perpétuelle évolution. C'est un secteur assez neuf. Si je prends l'exemple d'Eco-index, ça ne fonctionnait pas sur le site. Ils sont en train de mettre à jour une nouvelle version. On peut utiliser l'extension Chrome ou Firefox. Je voudrais attirer votre attention sur la CI. Ça va vous permettre de garantir la qualité de vos projets. Dans beaucoup de missions, j'ai vu des CI qui mettent plus de 30 minutes à s'exécuter. C'est très frustrant. J'ai le temps d'aller prendre plusieurs cafés et quand je reviens, ce n'est toujours pas terminé. En plus de prendre du temps, ce n'est pas neutre. C'est une machine qui va consommer du CPU, de la RAM et de la bande passante. Je vais essayer d'abord de l'optimiser. Je vais optimiser mes tests, je vais supprimer les doublons, je vais éviter les redondances. Il y a tout un tas de choses que notre CI va avoir un temps d'exécution plus court. Si vous êtes dans une équipe de 15 développeurs, ils vont pusher à longueur de journée et donc déclencher la CI à longueur de journée. Code propre et autonettoyant, ça devrait être la partie qui devrait le plus intéressé. Il est important de rappeler que la majeure partie de l'impact que l'on va pouvoir avoir, ça va se situer au niveau du produit.
_ Commencer par couper ce qui ne sert à rien et optimiser à la fin.
_ Comment je peux faire en tant que développeur pour améliorer mon environnement de développement ? Je parle de réduire mon impact environnemental. Est-ce que je vais avoir besoin de plusieurs écrans pour travailler ? On me répond souvent que c'est pratique. C'est un choix. Je suis parti sur du Linux. Le mode multi bureau fonctionne très bien. Est-ce que j'ai besoin d'avoir le dernier téléphone à la mode ? Est-ce que j'ai besoin d'avoir le dernier ordinateur le plus puissant ? La majorité de la pollution intervient dès la phase de fabrication des terminaux. S'il vous plaît, essayez de faire durer au maximum vos terminaux utilisateurs.
_ Du côté PO, c'est un intéressant d'avoir un environnement de test qui ne soient pas tous les terminaux de dernier cri. D'un point de vue fonctionnel, c'est très intéressant, de temps en temps, de garder des choses qui ne sont pas forcément dernier cri. Quand ça fonctionne, ça roule. On ne se rend pas compte qu'on est en train d'exclure des gens qui n'ont pas les moyens de changer de terminaux de façon aussi régulière que nous.
_ Je vais faire un rappel sur ce qu'est la performance. J'entends beaucoup trop avoir un site rapide, c'est avoir un site performant. Je le pensais, avant de découvrir la norme ISO 25010. La performance, c'est trois choses. C'est une application qui va répondre rapidement. Ça va être une application qui répond tout le temps. Peu importe le nombre d'utilisateurs que vous allez avoir, il faut que votre application puisse répondre à tout le monde. Troisième point, le plus important : avoir une application sobre. Il faut que votre application consomme le moins de ressources possibles. Si vous avez un site qui est rapide, mais qui nécessite plusieurs serveurs, vous n'aurez pas une application performante. Comment je peux faire pour rendre mon code plus vert ? Il va s'agir de faire de l'éco-conception. Ça va être d'intégrer l'environnement de la face de la conception d'un service numérique. L'éco-conception, c'est une norme ISO 14062. Ça va permettre d'éviter le greenwashing. C'est vraiment bullshit. Ici, je vais essayer de me focus sur des bonnes pratiques côté bac. Ici, on peut dire deux choses. Il vaut mieux privilégier du sur-mesure pour éviter tout ce qui est obésité fonctionnelle, uniquement répondre à mon besoin utilisateur. J'insiste là-dessus.
L'avantage d'un CMS, ça va être sa souplesse. Pour pouvoir être aussi souple, il va imposer certaines fonctionnalités. Il va être contraignant et consommé plus de ressources. Il faut se poser la question de ce que j'ai réellement besoin. Si c'est juste pour avoir un système de gestion de commentaire, pas forcément utile d'installer un CMS. Par contre, si j'ai besoin de l'ensemble des fonctionnalités, ça ne sert à rien de réinventer la roue. Alors le CMS peut paraître plus pertinent. Le choix des formats de données. Le type de données a un impact significatif sur tout ce qui va être consommation mémoire. Un mauvais typage peut avoir plusieurs conséquences dont le gaspillage de mémoire. Si vous stockez un petit élément, vous allez avoir du gaspillage. Si je stocke mon code postal dans un endroit prévu pour 250 caractères, c'est un problème. Je pense à Doctrine. Si on ne spécifie pas une longueur par défaut, il va partir sur 255 caractères. On pourrait avoir aussi des problèmes de performance. Il est beaucoup plus rapide de faire une recherche... Il faut éviter les requêtes SQL dans une boucle. Ça pose des gros problèmes de perf. Deuxièmement, ça va consommer uniquement de la mémoire de la bande passante. Je vous ai mis ici ce qu'il faudrait éviter dans le cadre où j'aimerais insérer un ensemble d'utilisateurs dans ma base de données. Il vaudrait mieux privilégier la deuxième solution. On parcourrait toujours notre table utilisateurs. On va faire quelques économies. Il faut optimiser les requêtes. La base de données, c'est la partie la plus importante dans votre application. Une requête mal optimisée va avoir des conséquences drastiques sur les performances et la consommation de ressources. Ici, j'ai volontairement mis Doctrine. C'est très bien, ça nous permet d'aller très vite, notamment sur les méthodes magiques.
Mais derrière, si j'utilise ce genre de méthodes sur des tables qui ont 50 colonnes, ça va tout récupérer. Est-ce que j'en ai réellement besoin ? Il vaut mieux récupérer uniquement les données dont j'ai besoin, les données dont mon frontend a besoin pour optimiser tout ça. Il faut plutôt privilégier du sur-mesure. Deuxième chose : on pourrait aussi mettre en place des LIMIT. Si jamais on a besoin de plus de données, on peut très bien mettre en place un système de pagination. On peut aussi créer des index sur les champs que l'on va solliciter pour optimiser une requête. Il faut mettre les caches en RAM. Les systèmes de cache doivent être montés en RAM. Ça va éviter les entrées et sorties sur le disque dur et donc les cycles CPU qui vont permettre de gérer tout ça. L'objectif va être de servir très rapidement le client et ça va être de limiter le nombre de composants matériels. Ici, je n'ai pas besoin de disque dur. L'accès à la RAM étant super rapide en lecture écriture, la durée de consommation des ressources s'en retrouvée réduite. On aime bien utiliser des systèmes cache comme Redis ou Varnish. Chez Fairness, dans le cadre d'un cache HTTP, on met en place un système de reverse proxy. Je n'ai pas de données en cache, je vais aller récupérer les données et je vais aller les mettre derrière mon système de cache. Mes 10 copains n'auront pas à faire le même chemin. Ensuite, il faut réduire nécessaire les logs serveurs. Ça va vous permettre d'avoir un suivi de ce qui se passe en production et de pouvoir intervenir très rapidement en cas de problème. Il faut quand même les configurer dans leur ensemble. Ce que je fais pour éviter de saturer les disques durs, je vais essayer de régler au plus juste le niveau des logs. Trop de logs tuent les logs.
L'objectif va être de réduire l'espace de stockage pour faire fonctionner le système de logs et de réduire les cycles CPU pour pouvoir les faire fonctionner. Ensuite, favoriser le request collapsing. Ça va vous permettre de limiter vos appels vers des services distants, en les regroupant en un seul appel. L'objectif va être multiple. Ça va être de limiter la charge sur le réseau, ça va être de limiter l'impact de latence d'une API. Si je fais trois appels, je serai d'autant plus impacté que si je n'en faisais qu'un seul. Enfin, ça va nous permettre de diminuer les coûts dans le cas où je fais appel à des services qui sont payants. Exemple concret : je suis client sur un site de commerce. J'ai besoin de récupérer les informations de la commande. L'application va aller récupérer les informations du produit, elle va les récupérer l'état du paiement, etc. En fonction de votre architecture, elle peut faire X requêtes. On va tout regrouper en une seule requête pour avoir un contenu plus optimisé. Ensuite, mettre en place une politique d'expiration et de suppression des données. On pourrait avoir différentes stratégies. Si on utilise un système de données comme du Redis ou du MongoDB, on peut spécifier un TTL sur une table ou une ressource spécifique. Ça va nous permettre de supprimer la donnée dès le TTL expiré. Ce qui n'est pas utile, on vire. Utiliser la version la plus récente du langage. C'est très important de suivre un langage. On le sait très bien, et langage évolue perpétuellement pour apporter de nouvelles fonctionnalités, pour apporter du gain de performance. Exemple concrète avec la sortie de PHP 7 par rapport à PHP 5. On a eu un énorme gain de performance. C'était assez significatif. Un autre point de vue plus personnel : j'ai trouvé que depuis la version de PHP 7, ça a permis de professionnaliser le langage. Idem avec la version de PHP 8, avec l'arrivée de JIT compiler. Ça va permettre de compiler une partie des codes et de les stocker en RAM. C'est quatre fois plus rapide, le tout en gérant mieux sa mémoire. C'est important de suivre l'évolution d'un langage. Tout le monde y gagne dans l'histoire. Il va y avoir le développeur, car c'est beaucoup plus simple et agréable de travailler sur langage rapide et professionnel. L'infrastructure, parce que votre langage sera plus rapide et consommera moins de ressources. Et enfin, votre utilisateur final, parce qu'il va avoir une application sobre, rapide et performante.
_ On arrive à la fin. Je sais qu'on a évoqué énormément de notions. Je pense qu'il y en aura certaines qui auraient besoin d'avoir des confs à elles toutes seules. J'espère vous avoir convaincu que cela est faisable. On peut avoir un impact sur la façon dont le numérique peut peser sur l'environnement et les utilisateurs. On est prêts à répondre à vos questions maintenant ou après.
_ On vous a aussi mis le QR code. N'hésitez pas à nous donner vos retours pour qu'on puisse s'améliorer. Merci.
_ Je ne sais pas si on a le temps pour des questions.
_ On a largement le temps.
_ Bonjour. Merci beaucoup d'aborder ce sujet hyper important. Je reviens au début de la conférence. Tu parlais d'"obésiciel". La plus grande partie de ce grossissement des applications vient du système d'exploitation. Windows XP devait peser des centaines de milliards. Maintenant, Android doit poser quelques gigas et rend les mêmes services malgré toutes les évolutions technologiques qu'on a pu mettre dedans. Au niveau des gros éditeurs, est-ce qu'il y a des initiatives dans le sens d'essayer de dégraisser le mammouth et d'avancer dans le bon sens ?
_ Ce n'est pas les systèmes d'exploitation, ce sont les fonctionnalités qui ne servent à rien. Essayez d'embarquer toutes vos équipes. Tous les métiers sont concernés, en particulier les clients, les PO, il faut vraiment dropper d'abord les fonctionnalités. Les gros systèmes d'exploitation sont conscients par ce qu'on leur crache dessus du fait que le numérique pollue. Les gros hébergeurs aussi sont conscients qu'il va falloir être un peu plus green. Google fait beaucoup de pub là-dessus. Il y en a qui sont concernés, mais maintenant, ça ne bouge pas assez vite. Quand je vous dis qu'on est de deux à cinq ans de ressources d'Indiens, ce n'est pas moi qui l'aie inventé. Est-ce qu'on ne peut pas garder des OS qui sont plus anciens ? Il faut continuer à faire marcher vos devices anciens de vos utilisateurs et leur faire des retours réguliers en leur disant qu'il faudrait dégraisser aussi un peu les choses. C'est un travail d'équipe. On a tous notre taf à faire là-dessus.
_ [Propos en anglais]
_ Je ne sais pas si c'est prévu par l'AFUP.
_ Est-ce que vous avez prévu de transcrire votre talk en anglais ?
_ [Propos en anglais] Oui, on pourrait le faire.
_ On a encore du temps pour les questions.
_ Bonjour. Vous avez parlé des "obésiciels". Je vois beaucoup de développeurs qui utilisent Symfony. C'est 3000 classes. Il y a énormément de sites ou de logiciels qui utilisent grosso modo une petite partie de Symfony pour faire du crud. Est-ce qu'on a vraiment besoin des frameworks ? Doctrine nous en avait parlé. Ne doit-on pas essayer de se passer de ces outils qui laissent du travail à faire à la machine ?
_ Les frameworks sont indispensables dans nos métiers de développeurs, peu importe le nombre de classes. Ça va nous permettre d'avoir un code de qualité, qui va être durable. Ils se seront déjà cassé les dents pour essayer d'améliorer les performances. Symfony ne cesse d'évoluer. Doctrine, tout va dépendre de ton utilisation. Tu peux très bien faire des requêtes complètement personnalisées, comme si tu faisais du vrai SQL. La majeure partie de l'impact que l'on va pouvoir avoir, c'est au niveau du produit. Plus on a dégraissé au niveau du produit, mais ce sera. On peut optimiser au niveau code, mais ça ne sera pas la grosse partie de l'impact. Je ne sais pas si ça répond à ta question.
_ Si vous êtes capables de faire du sur-mesure en PHP... Symfony, ça permet de faire quelque chose de propre, même si on n'a pas la capacité de faire du PHP. Ça va parfois être plus lourd qu'un Symfony bien utilisé.
_ Est-ce qu'il y a un enjeu d'éteindre le serveur et l'application ? La nuit, ils ne s'en servent pas. Le bar est parfois fermé aussi.
_ Je suis en mission chez Radio France. Ils ont déjà fait un premier pas vers ça, pour éteindre les environnements de préprod et de staging le soir. La production, c'est compliqué en fonction de la volumétrie des utilisateurs. Chez Radio France, c'est impossible pour la production, mais pour les environnements de recettes, ça a déjà été fait.
_ Ça dépend de votre produit. Il faut réfléchir produit, prendre du recul pour essayer d'être pertinent sur ce dont on a vraiment besoin. Si j'ai un service qui va tourner... J'ai été coach de La Poste, je leur demandais s'ils avaient vraiment besoin de l'intranet. Après, je me suis dit que dans les îles, ils utilisent la même chose. Ils avaient besoin de le laisser parce qu'ils continuaient à tourner en outre-mer. Ça permet d'identifier les choses qui tournent dans le vide que l'on peut optimiser. Tout ce qui est prod et préprod, environnement de recettes, dès qu'on ne l'utilise pas, on peut l'éteindre.
_ Merci beaucoup.
_ N'hésitez pas à venir nous voir pendant la journée. On sera encore là. Merci.
Tweets