Table des matières de l'article :
Dans le monde de l’hébergement web et de la gestion d’infrastructures, AWS (Amazon Web Services) est souvent considéré comme la référence en matière d’évolutivité et de fiabilité. Cependant, comme tout outil puissant, le succès d'AWS dépend de sa configuration et de sa gestion appropriées. Cet article analyse un cas concret de site d'astronomie, passionastronomia.it, qui a subi un temps d'arrêt de 4 heures malgré son hébergement sur AWS. Nous explorerons les causes du problème, l'utilisation de CloudFront et CloudFlare et l'importance du cache pleine page pour améliorer les performances et réduire la consommation de ressources.
Le cas : passionastronomia.it
Il y a quelques mois, l'un de nos précieux clients avec un trafic mensuel d'environ 50 millions de pages vues, nous a signalé un site d'astronomie émergent qui rencontrait périodiquement des problèmes de temps d'arrêt en raison d'un trafic trop important.
Lui, qui suivait la page Passione Astronomia, a été informé par les posts publiés sur Facebook par Passione Astronomia elle-même. Chaque fois qu'une publication provoquait une surcharge et que le site était hors ligne, ils le signalaient, se vantant que le serveur ne pouvait pas gérer le trafic élevé.. Or, pour le propriétaire d'un site habitué à gérer 50 millions de pages vues par mois, avec des pointes à plus de 3 millions par jour, il est assez « curieux » de voir comment un site qui en gère environ un dixième, soit environ 6 millions par mois (selon les estimations de SimilarWeb), peuvent se déconnecter très fréquemment sans que personne ne fasse quoi que ce soit pour résoudre le problème.
C'est vraiment un problème, car normalement, lorsqu'un temps d'arrêt se produit et que le trafic dirigé vers le site est incapable de le contacter ou accumule de nombreuses erreurs 500, les navigateurs qui utilisent Chromium (le moteur derrière Chrome), y compris évidemment Chrome, signalent l'incident à Google. En conséquence, Google enverra moins de trafic vers ce site dans les heures suivantes, sachant que quelque chose ne fonctionne pas correctement. Cela peut avoir un impact important sur la visibilité et les performances du site, pénalisant encore davantage son trafic et sa fiabilité aux yeux des utilisateurs et des moteurs de recherche, en plus de nuire évidemment à son image.
De plus, même lorsque le site est en ligne, il ne semble pas garantir on ne sait quelles performances avec un Time To First Byte d'environ 500ms à 8h du matin avec un site pratiquement peu visité et sans posts lancés générant du trafic. Ci-dessous, vous pouvez par exemple consulter le test TTFB pour l'Europe avec le test TTFB SpeedVitals.com
Ci-dessous vous pouvez consulter notre TTFB de Managedserver.it, un site dont nous prenons soin de manière obsessionnelle pour obtenir les meilleures performances.
Nous parlons d'un TTFB (Time to First Byte) 10 fois inférieur et bien en dessous du maximum de 200 ms que Google considère acceptable avant de signaler que le temps de réponse du serveur est trop élevé, indiquant la nécessité « d'améliorer le temps de réponse du serveur ». .
De plus, la lenteur d'un TTFB aussi élevé, au point de devenir fréquemment inatteignable à certains moments de la journée, y compris lors d'arrêts prolongés, affecte négativement le Vitaux Web de base ce que nous pouvons voir dans le rapport Google PageSpeed Insight ci-dessous.
Un délai élevé jusqu'au premier octet (TTFB), comme le montre l'image avec une valeur de 2,3 secondes, peut affecter négativement d'autres paramètres du Vitaux Web de base. Un TTFB élevé signifie qu'il y a un délai important avant que le navigateur ne commence à recevoir des données du serveur. Ce délai contribue à un First Contentful Paint (FCP) élevé (3,4 secondes) et à un Largest Contentful Paint (LCP) élevé (4,7 secondes), car le rendu initial de la page est retardé. De plus, un TTFB élevé peut avoir un impact négatif sur l'interaction avec Next Paint (INP) et le décalage cumulatif de mise en page (CLS), car un chargement lent des pages peut conduire à une expérience utilisateur moins fluide et à des changements de mise en page plus fréquents.
Habitué à gérer des pics de trafic importants, voire supérieurs à 2 millions de visites par heure et 200 mille par minute, et spécialisé dans l'optimisation de Vitaux Web de base, nous avons proposé nos services et notre expertise aux propriétaires de passionastronomia.it en les contactant pour leur proposer une gestion gérée de leur infrastructure ou migrer vers notre hébergement performant, cependant, notre offre a probablement été mal comprise et sous-estimée, voire rejetée sans trop de compliments et de mots hachés.
Pourtant, notre site bénéficie d'un TTFB optimal de seulement 22 ms en Italie et d'un PageSpeed qui passe brillamment le test de Vitaux Web de base comme vous pouvez le voir ci-dessous.
Avec un portefeuille de clients éditeurs important et les chiffres évoqués ci-dessus, qui ont pu être évalués de manière impartiale grâce aux outils mis à disposition par Google, il semblait incroyable que, dans un moment de difficulté caractérisé par des temps d'arrêt continus, ils n'aient pas profité de l'occasion pour résoudre tous les problèmes en un éclair. Cela aurait pu se produire à un coût probablement deux fois moins élevé que celui de leur fournisseur actuel, qui les voyait souvent hors ligne ou avec des performances médiocres, comme l'indiquent les tests ci-dessus.
Passioneastronomia.it et WordPress
Passioneastronomia.it est un site éditorial développé sous WordPress, basé sur PHP et MySQL. Bien que ces technologies soient désormais considérées comme obsolètes par rapport aux langages et technologies plus modernes et asynchrones comme Node.js, Go ou les bases de données NoSQL comme Cassandra, MongoDB ou REDIS, elles continuent d'être largement utilisées. PHP, par exemple, a été développé dans les années 90 et a subi de nombreuses mises à jour au fil du temps, mais reste moins performant dans les situations de charge élevée que les langages asynchrones modernes. De même, MySQL, bien qu'il s'agisse d'un système de gestion de bases de données relationnelles robuste, peut rencontrer des difficultés en termes d'évolutivité et de performances lors du traitement de gros volumes de données et de requêtes simultanées.
Malgré ces limites, WordPress reste le système de publication de contenu le plus polyvalent et le plus facile à mettre en œuvre disponible aujourd'hui. Sa vaste communauté de développeurs, sa myriade de plugins disponibles et son interface intuitive en font un choix populaire aussi bien pour les petits blogs que pour les grandes entreprises. Même les grands journaux comme Le Quotidien Made ils utilisent WordPress comme CMS pour publication éditoriale, démontrant qu'avec la bonne configuration et optimisation, il est possible d'obtenir d'excellentes performances même avec des technologies considérées comme moins modernes.
en outre même la NASA, la plus haute expression de l’imaginaire collectif de diffusion scientifique, utilise WordPress comme CMS.
Passioneastronomia.it initialement (du moins depuis qu'ils nous en ont parlé il y a environ un an) était hébergé sur SiteGround, un service d'hébergement qui n'est pas toujours en mesure de gérer un trafic de ce niveau. Puis en avril, le site a migré vers AWS, le choix du marché et de nombreux grands noms comme Netflix, Airbnb, Spotify, Twitch, LinkedIn, Adobe, Slack et la BBC.
- Netflix: Utilise AWS pour le streaming vidéo, le stockage de données et l'analyse.
- Airbnb: exploite AWS pour gérer sa plateforme hôtelière mondiale et son marché en ligne.
- Spotify: utilisez AWS pour la diffusion de musique en streaming, l'analyse de données et l'apprentissage automatique.
- Twitch: La plateforme de streaming vidéo appartenant à Amazon s'appuie sur AWS pour la transmission vidéo en direct et la gestion des données.
- LinkedIn: Bien qu'une partie de son infrastructure soit interne, LinkedIn utilise AWS pour certains de ses services de stockage et d'analyse de données.
- Adobe: Propose ses services Creative Cloud et d'autres applications SaaS via AWS.
- Slack: Utilise AWS pour sa plateforme de messagerie et de collaboration.
- BBC: La BBC utilise AWS pour la diffusion de contenu vidéo à la demande et la gestion des données.
Malgré la puissance et l'évolutivité d'AWS, passionastronomia.it a continué à connaître des temps d'arrêt, aboutissant à une panne de 4 heures le 16 mai, de 19h à 00h23, surveillée par notre outil Uptime Kuma.
Les causes des temps d'arrêt
Le principal problème ne réside pas dans AWS en tant qu'infrastructure, mais dans la configuration et la gestion du service. AWS propose une large gamme de services, notamment EC2, des bases de données, des équilibreurs de charge, des systèmes de fichiers distribués et des CDN comme CloudFront.. Cependant, s'il est utilisé de manière inappropriée, AWS peut entraîner de graves problèmes de performances.
Le site passionastronomia.it ne disposait pas d'un système Full Page Cache adéquat tel que CloudFront ou la version Pro ou Business de CloudFlare avec support HTML Cache, ni même d'un « simple » Varnish. Les en-têtes de réponse du site montrent clairement que la mise en cache HTML n'était pas activée :
HTTP/2 200 date: Thu, 16 May 2024 22:02:18 GMT content-type: text/html; charset=UTF-8 set-cookie: AWSALBTG=gkrvkTmzuBE7uhKteG6ihiCGQH60BIdF48ki+7cvKP9ia2ltc4cAgn5dVM5l+/WaO8fbb8dzylYF1OYP7PZnmhHdLsauuVLuLntiKviIt8EAxKNbM3yBSyKqrMaGu1SXAQaPGkLnjoHwqz3OkmDHAVqvBB0V3v4d0WOcshbhqixspvTJTic=; Expires=Thu, 23 May 2024 22:02:17 GMT; Path=/ set-cookie: AWSALBTGCORS=gkrvkTmzuBE7uhKteG6ihiCGQH60BIdF48ki+7cvKP9ia2ltc4cAgn5dVM5l+/WaO8fbb8dzylYF1OYP7PZnmhHdLsauuVLuLntiKviIt8EAxKNbM3yBSyKqrMaGu1SXAQaPGkLnjoHwqz3OkmDHAVqvBB0V3v4d0WOcshbhqixspvTJTic=; Expires=Thu, 23 May 2024 22:02:17 GMT; Path=/; SameSite=None; Secure cf-edge-cache: cache,platform=wordpress link: <https://www.passioneastronomia.it/wp-json/>; rel="https://api.w.org/" link: <https://www.passioneastronomia.it/wp-json/wp/v2/pages/49>; rel="alternate"; type="application/json" link: <https://www.passioneastronomia.it/>; rel=shortlink vary: Accept-Encoding cf-cache-status: DYNAMIC report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=dvOaq3CI0sDGSeXsjICpJUT0nF1zmp%2BFj1TKPfqJKvyRd%2FuybtNnkc9FKE6SLu7CldFY7brUo1HZwF1kvPoDyisecYzzZC3aI%2FlrjkKCKcs%2BD4LVRylVZMmSQViSYJRA6fO9JU1sg2ejKUk%3D"}],"group":"cf-nel","max_age":604800} nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800} server: cloudflare cf-ray: 884ea6b518c20e4d-MXP alt-svc: h3=":443"; ma=86400
La version gratuite de CloudFlare ne prend pas en charge le cache HTML en mode DYNAMIQUE, provoquant une charge excessive sur les serveurs AWS avec des requêtes HTML continues passant directement par les processus PHP et les connexions aux bases de données.
Dans le premier cas, lorsque la charge augmente de manière significative, le serveur Web d'origine atteint la saturation, étant incapable même de répondre et provoquant l'expiration du proxy inverse du CDN CloudFlare comme dans l'image suivante :
Dans le deuxième cas, même si le serveur Web parvient à répondre pendant quelques instants, le chargement des requêtes SQL sur la base de données MySQL renverra certainement une erreur de connexion à la base de données comme dans la capture d'écran ci-dessous.
Plus succinctement, il est correct de dire, sans trop entrer dans le monde des SGBD, de la gestion des tables, des requêtes et des index, que ce manque de mise en cache adéquate a plusieurs implications négatives, en particulier pour les sites à fort trafic tels que passionastronomia.it.
Implications du manque de cache HTML
- Charge accrue sur les serveurs Origin:Sans mise en cache HTML, chaque requête de page HTML doit être traitée directement par les serveurs d'origine. Cela signifie que chaque visite sur le site active les processus PHP pour générer le contenu dynamique de la page, augmentant considérablement la charge sur les serveurs. En conséquence, le serveur doit gérer un grand nombre de requêtes simultanées, entraînant un épuisement rapide des ressources disponibles.
- Surcharge de base de données:Chaque requête HTML peut impliquer une série de requêtes de base de données pour récupérer les données nécessaires à la génération de la page. À mesure que le trafic augmente, le nombre de connexions à la base de données peut dépasser la limite gérable, provoquant un ralentissement, voire une panne de la base de données. Cette surcharge de base de données est souvent à l’origine d’un temps d’arrêt prolongé.
- Temps de réponse élevés:Sans mise en cache, le temps nécessaire pour générer une page HTML peut être considérablement plus long. Chaque requête nécessite le chargement et l'exécution de scripts PHP, l'interaction avec la base de données et la génération dynamique de contenu. Ce processus est beaucoup plus lent que la diffusion d'une page en cache, ce qui entraîne des temps de réponse élevés et une expérience utilisateur sous-optimale.
- Risque de temps d'arrêt:Lorsque les serveurs d'origine sont constamment sous pression en raison du nombre élevé de requêtes, le risque de temps d'arrêt augmente. Les serveurs peuvent ne plus répondre ou même planter si la charge dépasse leur capacité à gérer. C'est exactement ce qui est arrivé à passionaastronomia.it, où le site a connu des temps d'arrêt importants en raison de l'incapacité de gérer un trafic élevé sans un système de mise en cache approprié.
Utilisation inappropriée d'AWS EC2
Bien qu'AWS EC2 soit une solution puissante, l'utilisation d'une instance EC2, même une grande Etra, sans configuration appropriée, peut s'avérer inefficace. Une instance EC2 n’est rien d’autre qu’une instance virtualisée dotée d’une certaine quantité de cœurs et de RAM, qui offre des ressources de calcul importantes. Cependant, sans une gestion du trafic et une mise en cache appropriées, ces ressources peuvent rapidement devenir surchargées. Une mauvaise configuration peut transformer une instance puissante en un goulot d'étranglement, incapable de gérer des pics de trafic élevés.
Par exemple, en l'absence de mécanismes d'équilibrage de charge, un serveur unique peut être submergé par un trop grand nombre de requêtes simultanées, épuisant rapidement le processeur et la mémoire disponibles. De plus, sans stratégie de mise en cache efficace, chaque requête utilisateur doit être entièrement traitée par le serveur d'origine, impliquant des processus PHP et des requêtes de base de données pour générer les pages dynamiques. Cela augmente non seulement les temps de réponse, mais cela met également à rude épreuve la base de données, ce qui peut devenir un point de défaillance critique bien que, comme nous pouvons le voir, la base de données soit hébergée sur un service de base de données gérée tel que RDS.
MySQL RDS (service de base de données relationnelle) par Amazon AWS est un service de base de données géré qui facilite la configuration, l'exploitation et la mise à l'échelle d'une base de données MySQL dans le cloud. Avec MySQL RDS, Amazon s'occupe des tâches administratives telles que le matériel, le système d'exploitation, les correctifs de base de données et les sauvegardes. Cela permet aux utilisateurs de se concentrer davantage sur le développement d'applications et moins sur la gestion de l'infrastructure.
Même les meilleures instances EC2 peuvent donc échouer si elles ne sont pas prises en charge par une architecture backend solide. Pour maximiser l'efficacité d'une instance EC2, il est essentiel de mettre en œuvre des systèmes de mise en cache au niveau des applications et d'utiliser des CDN comme CloudFront ou CloudFlare pour répartir la charge. De plus, la configuration d'Auto Scaling pour s'adapter automatiquement aux changements de trafic peut éviter les surcharges soudaines. Ce n'est qu'avec une gestion minutieuse et une configuration optimale qu'une instance EC2 peut exploiter pleinement son potentiel, garantissant des performances et une fiabilité élevées.
Que sont CloudFront et CloudFlare ?
CloudFront
CloudFront est un CDN (Content Delivery Network) proposé par AWS qui diffuse du contenu dans le monde entier, réduisant ainsi la latence et améliorant la vitesse de chargement des pages. Ce service est particulièrement utile pour les sites à fort trafic tels que passionastronomia.it, car il est capable de mettre en cache des pages HTML entières, réduisant ainsi la charge sur les serveurs d'origine et améliorant considérablement l'expérience utilisateur. La fourniture de contenu via un réseau mondial de nœuds périphériques rapproche les données des utilisateurs finaux, ce qui se traduit par des temps de réponse plus rapides et une plus grande fiabilité. De plus, CloudFront offre des fonctionnalités avancées telles que la protection DDoS et l'intégration avec AWS Shield et AWS WAF, qui contribuent à améliorer la sécurité du site. L'utilisation de CloudFront vous permet également de mieux gérer les pics de trafic, en garantissant que les ressources du serveur d'origine ne sont pas surchargées pendant les périodes de forte demande. Sa flexibilité et son évolutivité en font une solution idéale pour améliorer les performances du site et offrir une expérience de navigation plus fluide et plus rapide aux utilisateurs.
CloudFlare
CloudFlare est un autre service CDN qui offre une large gamme de fonctionnalités pour améliorer les performances et la sécurité des sites Web. Contrairement à CloudFront, CloudFlare propose plusieurs options de mise en cache, notamment HTML Cache pour les versions Pro et Business.
Les avantages de CloudFront et CloudFlare peuvent être très similaires, voire se chevaucher. L'avantage le plus connu de CloudFlare par rapport à CloudFront est que CloudFlare propose un plan tarifaire forfaitaire avec un plan de base de 25 $ par mois. ce qui aurait été largement suffisant pour rendre le site passionastronomia.it parfaitement conforme aux pics de trafic qu'il reçoit quotidiennement.
CloudFront, en revanche, propose un plan de paiement à l'utilisation, de sorte que le coût est directement proportionnel aux données déplacées.
En fait, CloudFlare et CloudFront proposent tous deux un service Full Page Cache en mode PaaS (Platform as a Service), se distinguant des solutions auto-hébergées telles que Varnish Cache. Cette différence est significative, car un service PaaS comme celui fourni par CloudFlare et CloudFront vous évite d'avoir à gérer et à maintenir l'infrastructure de mise en cache. Avec les solutions PaaS, le déploiement et la gestion du cache sont automatisés et intégrés au service, réduisant ainsi les frais administratifs et permettant aux équipes de se concentrer sur d'autres tâches critiques.
Par exemple, CloudFlare et CloudFront proposent des interfaces conviviales pour configurer les règles de mise en cache., gérez les invalidations et surveillez les performances du site, le tout sans nécessiter de compétences techniques approfondies en gestion de serveur. En revanche, les solutions auto-hébergées telles que Varnish Cache nécessitent une configuration manuelle et une gestion continue de l'infrastructure de mise en cache. Cela implique la nécessité de disposer d'un personnel technique qualifié capable d'installer, de configurer, de surveiller et de mettre à jour le logiciel de mise en cache, ainsi que de gérer les serveurs physiques ou virtuels sur lesquels il opère.
Les solutions PaaS de CloudFlare et CloudFront offrent également un avantage significatif en termes d'évolutivité et de fiabilité.. En tant que services cloud, ils peuvent tirer parti du réseau mondial de nœuds distribués pour offrir des performances élevées et une faible latence aux utilisateurs finaux, quelle que soit leur situation géographique. La fourniture de contenu sur un réseau mondial de serveurs périphériques réduit la latence et améliore les temps de chargement des pages, offrant ainsi une expérience utilisateur optimale.
De plus, CloudFlare et CloudFront intègrent des fonctionnalités de sécurité avancées, telles que la protection DDoS et l'intégration avec les certificats SSL, qui peuvent être gérées et configurées directement depuis la plateforme sans nécessiter d'intervention manuelle. Ce niveau d'automatisation et d'intégration facilite la sécurisation des applications Web et offre une plus grande tranquillité d'esprit aux propriétaires de sites.
Bien que les solutions auto-hébergées telles que Varnish Cache puissent offrir un contrôle plus granulaire et personnalisé sur la configuration du cache, elles nécessitent un engagement important en termes de ressources et d'expertise technique. D'autre part, les solutions CloudFlare et CloudFront PaaS fournissent un service complet, automatisé et hautement évolutif qui simplifie la gestion du cache, réduit la charge administrative et offre un niveau plus élevé de performances et de sécurité.
Cache pleine page, qu'est-ce que c'est ?
Full Page Cache (FPC) est une technique de mise en cache qui stocke l'intégralité de la page HTML générée par un site Web. Cette technique est essentielle pour les sites à fort trafic car elle réduit considérablement le nombre de requêtes adressées au serveur d'origine, réduisant ainsi la charge de travail des processus PHP et des connexions aux bases de données.
Comment Acheter
Lorsqu'un utilisateur visite une page Web, le serveur génère la page HTML et la met en cache. Les visites ultérieures sur la même page sont servies directement à partir du cache, évitant ainsi la régénération de la page et réduisant les temps de réponse.
conclusion
L'absence de cache HTML est un exemple classique de la façon dont l'absence d'une stratégie de mise en cache adéquate peut mettre à rude épreuve même les infrastructures les plus robustes comme AWS. Pour les sites à fort trafic, la mise en œuvre d'un système de mise en cache efficace est cruciale pour réduire la charge sur les serveurs d'origine, améliorer les temps de réponse et éviter des temps d'arrêt importants. Dans ce cas précis, il aurait suffi d'utiliser la version mensuelle de CloudFlare à 25 $, configurée par un bon ingénieur système, pour résoudre les problèmes de temps d'arrêt. Mieux encore, implémenter un système Varnish Cache avec CloudFlare placé devant aurait permis une double couche de cache. Cette configuration aurait offert des performances maximales à un coût certainement inférieur à celui actuel. Grâce à de telles solutions, il est possible d'obtenir des améliorations significatives des performances et de la stabilité du site, garantissant une expérience utilisateur optimale même pendant les pics de trafic.
Cela montre qu'au-delà du fournisseur des services que vous décidez d'utiliser, ce qui compte vraiment, c'est la compétence technique et l'expertise des techniciens chargés de mettre en œuvre la meilleure stratégie de mise en cache afin d'améliorer les performances et la diffusion du contenu.
Vous trouverez ci-dessous le trafic du site de notre client que l'équipe éditoriale de Passionastronomia.it nous a signalé pour des problèmes que nous aurions pu résoudre en 1 heure de travail et de conseil, économisant probablement environ 75% du budget qu'ils dépensent sur AWS pour se déconnecter. . Mais comme on dit dans ces cas-là, celui qui est la cause de son propre mal devrait pleurer pour lui-même.
Ce sera drôle quand les "factures" arriveront d'AWS et notamment d'Amazon RDS pour MySQL qui est un service Pay Per Use et qui va probablement augmenter considérablement les coûts. L'ingénierie des systèmes n'est pas un jeu d'enfant et comme vous pouvez le constater, des consultants techniques inexpérimentés peuvent non seulement causer des dégâts, mais aussi épuiser votre budget, sans savoir à quel point il pourrait être plus pratique de dépenser en investissant dans le CDN et le Full Page Cache, plutôt que dans le Managed. Services de base de données comme AWS RDS.
Nous lui avons dit…
Mises à jour deux mois plus tard.
Suite à ce post et aux réflexions présentes, nous avons pensé qu'il était correct (mais pas nécessaire) de partager quelques suggestions techniques avec la société Passione Astronomia. Nous avons donc envoyé un email contenant des conseils techniques extrêmement précis et utiles pour le scénario d'hébergement actuel sur Amazon AWS, conseillant donc d'installer soit un cache pleine page côté serveur tel que CloudFront d'Amazon, soit d'activer le cache HTML CloudFlare qu'ils utilisent déjà en mode gratuit, peut-être en utilisant directement l'APO de CloudFlare à un faible coût d'environ 5 dollars par mois.
Nous espérions avec confiance que d'ici quelques jours nous verrions nos précieuses suggestions techniques mises en œuvre, cependant après presque deux mois, l'analyse des en-têtes de réponse ne montre aucun changement en cours, pas même l'ombre de Cloudfront, de CloudFlare qui pas même l'ombre de Cache HTML et un temps de réponse dépassant les 200 ms maximum tolérés par Google.
La preuve du 9 a été donnée par l'arrêt du 8 juillet 2024, c'est-à-dire hier, le soir où notre système de surveillance Uptime Kuma nous a signalé un arrêt prolongé du site en question, avec une mise hors ligne totale et complète de 2 heures et 20 minutes , comme nous pouvons le voir sur le tableau de bord suivant.
Nous avons été assez choqués par le fait que nos conseils, totalement désintéressés et basés sur des années d'expérience, n'ont été ni reçus ni mis en œuvre. C'est particulièrement surprenant si l'on considère que certaines des maisons d'édition les plus grandes et les plus importantes de la scène italienne sont prêtes à payer plusieurs milliers d'euros pour résoudre des problèmes de stabilité, de rapidité et de performance que nous sommes capables de traiter efficacement.
Cela nous amène à une réflexion légitime : les opérateurs du secteur, ainsi que nos éventuels « collègues », sont-ils réellement conscients des pierres angulaires nécessaires à la gestion d'un projet important et réussi comme celui-ci ? Le moment est peut-être venu de réfléchir sérieusement à la création d'un registre professionnel avec un examen d'État pour accéder à des professions telles que l'ingénierie système. Une telle mesure garantirait des normes élevées de compétence et de responsabilité, garantissant que seuls les professionnels les plus formés puissent opérer dans un secteur si crucial pour le succès des entreprises modernes.