TheCodM | TheCodingMachine

Comprendre les méthodologies de projet web à toutes les étapes : du Design Thinking au DevOps, en passant par l’agile !

Posted on 22 janvier 20249 février 2024 by TheCodM

Présentation des méthodologies de projet web, du design thinking au DevOps

Il y a beaucoup de méthodologies de projet web différentes et certains pourraient se perdre dans cette forêt de bonnes pratiques ! Surtout que lorsque l’on ne maîtrise pas très bien ces notions, il y a le risque de passer pour quelqu’un qui n’est pas très moderne par les gourous de ces méthodes !

Malgré cet écueil, s’interroger sur ses pratiques, sur la manière d’être le plus efficace, sur ce qui permet d’apporter plus de valeur aux projets est nécessaire. Les méthodologies de projet web évoluent constamment pour s’adapter à la fois aux nouvelles technologies, aux besoins changeants des organisations ou même aux différentes envies des collaborateurs !

Alors faisons un tour de ces nouvelles méthodologies de projet web. Ces approches ne s’excluent pas les unes des autres, elles sont même assez complémentaires ! Tant pis pour les puristes, mais grossièrement, le design thinking permet de concevoir un produit, les méthodes agiles de le développer et le DevOps de le mettre en production…

DESIGN THINKING : un voyage créatif centré sur l’utilisateur, c’est l’art de donner vie à des idées par le prototypage et le test.

Le design thinking est une approche de résolution de problèmes centrée sur l’humain et axée sur la créativité. Elle met l’accent sur la compréhension approfondie des besoins, des motivations et des comportements des utilisateurs finaux pour créer des solutions innovantes et adaptées. Le design thinking est souvent utilisé dans le développement de produits, la conception de services, l’amélioration des processus et la résolution de problèmes complexes.

Elle comporte trois étapes clés :

#1 – Idéation : À cette étape, les membres de l’équipe génèrent un grand nombre d’idées de solutions potentielles, souvent par le biais de sessions de brainstorming. L’objectif est de penser de manière créative.

#2 – Prototypage : L’équipe sélectionne ensuite les idées les plus prometteuses et les transforme en prototypes concrets. Les prototypes peuvent être des maquettes, des maquettes numériques, des scénarios d’utilisation, ou d’autres représentations visuelles des solutions potentielles.

#3 – Test et itération : Les prototypes sont ensuite testés auprès des utilisateurs finaux pour recueillir des commentaires et des retours d’information. Ces tests permettent d’identifier ce qui fonctionne et ce qui doit être amélioré. En fonction des résultats, l’équipe itère en modifiant et en améliorant les prototypes.

Cette méthodologie repose sur l’idée que les meilleures solutions émergent lorsque l’on combine une compréhension profonde des besoins des utilisateurs avec un processus itératif de conception et de test. Il encourage la créativité, la collaboration et l’innovation, et peut être appliqué dans de très nombreux domaines, de l’entreprise à l’éducation en passant par le secteur public. Le design thinking permet de résoudre des problèmes de manière holistique et centrée sur l’expérience de l’utilisateur.

MÉTHODOLOGIE AGILE (SCRUM) : adieu la rigidité ! Embrassez l’adaptabilité et la collaboration. Fonctionnez par sprints pour dynamiser votre développement et maximiser la satisfaction client.

SCRUM (qui est la méthodologie agile la plus répandue) est basé sur des principes de travail en équipe, de transparence, d’adaptabilité et d’itérations. Il divise le projet en itérations appelées sprints, généralement de deux à quatre semaines. Chaque sprint se concentre sur la réalisation d’un ensemble de fonctionnalités définies dans un backlog de produit. Les équipes de développement se réunissent régulièrement pour des réunions de planification, de revue et de rétrospective pour s’organiser, inspecter leur travail et s’améliorer continuellement.

SCRUM permet une adaptation continue aux besoins changeants du projet. Les fonctionnalités peuvent être priorisées et ajustées à chaque sprint. Cette méthodologie encourage la collaboration étroite entre les membres de l’équipe et les parties prenantes. Les sprints réguliers permettent des livraisons partielles du produit, ce qui permet de réduire les risques en identifiant rapidement les problèmes et d’améliorer la satisfaction du client grâce à son implication dans le projet.

Les méthodologies de projet web hybrides combinent des éléments d’approches traditionnelles (comme le modèle en cascade) avec des méthodes agiles pour offrir plus de flexibilité tout en répondant aux exigences de planning ou de budgets.

DEVOPS : l’union sacrée du développement et des opérations, automatisant et fluidifiant le déploiement de vos logiciels pour une performance inégalée.

DevOps vise à intégrer étroitement le développement (Dev) et les opérations (Ops) pour accélérer la livraison de logiciels, améliorer la qualité et automatiser les processus de déploiement. Le DevOps est une approche culturelle, organisationnelle et technique du développement logiciel qui vise à améliorer la collaboration, l’efficacité et la qualité du cycle de vie du développement et de la livraison de logiciels.

Le DevOps repose sur plusieurs principes clés :

#1 – Collaboration étroite : les équipes de développement et d’exploitation travaillent ensemble de manière étroite et collaborative. Il n’y a plus de silos organisationnels, et les équipes partagent la responsabilité du cycle de vie du logiciel.

#2 – Automatisation : l’automatisation est au cœur du DevOps. Les processus, les tâches répétitives et les opérations sont automatisés autant que possible, ce qui réduit les erreurs humaines, accélère la livraison et assure la cohérence. Les tests unitaires font par exemple souvent parti des automatisations mises en place.

#3 – Livraison continue : le DevOps favorise la livraison continue de logiciels, ce qui signifie que les mises à jour et les fonctionnalités peuvent être déployées fréquemment et rapidement.

#4 – Surveillance et gestion des incidents : les équipes DevOps sont responsables de la surveillance en temps réel des performances et de la disponibilité des applications. En cas de problème, elles sont prêtes à réagir rapidement et à résoudre les incidents.

La mise en oeuvre du DevOps passe par des outils et des pratiques tels que l’intégration continue (CI), la livraison continue (CD), les outils d’automatisation, la gestion de configuration, les conteneurs, l’orchestration de conteneurs, la surveillance des performances, la gestion des incidents, etc.

Les avantages sont principalement l’amélioration de la qualité du logiciel grâce à des tests automatisés et à des déploiements plus fréquents et la réduction des erreurs humaines grâce à l’automatisation.

Pour conclure

Nous devons faire un avertissement sur un constat que nous faisons régulièrement : trop de méthodologie tue le projet. Lorsque l’attention de l’équipe est plus centrée sur la bonne exécution de la méthodologie que sur l’aboutissement du projet, le projet est en risque. Alors agir de manière méthodique est très important parce que cela fait gagner du temps et réduit les risques mais il ne faut pas perdre de vue ce que l’on doit faire in fine.

Finalement chacune des méthodologies décrites se spécialise sur une phase d’un projet : le Design Thinking pour la conception, les méthodologies agiles pour le développement et le DevOps pour la phase de production. Elles sont bien souvent complémentaires !

Peut-être que nous allons voir émerger dans un futur proche de plus en plus de méthodologies de projet web intégrant de l’intelligence artificielle et de l’apprentissage automatique dans la gestion de projet. Cela aiderait à prévoir des problèmes potentiels ou d’optimiser des ressources… à suivre donc !

Si vous avez un projet et que vous vous interrogez sur quelle méthodologie utiliser, n’hésitez pas à nous contacter !

Prix d’un projet web : les clés pour estimer votre budget avec TheCodingMachine

Posted on 6 décembre 20239 février 2024 by TheCodM

Quel est le prix d’un projet web ? Voici une question à laquelle nous devons souvent répondre. Et, ce n’est pas si simple, très souvent, la question est posée après une première réunion d’une heure et nous n’avons que quelques éléments à l’esprit…

Si on devait faire un parallèle, cette question sonne alors un peu comme si vous demandiez chez un concessionnaire : “Quel est le prix d’une voiture ?”. Il vous répondrait : ”C’est-à-dire que cela dépend ! Vous voulez rouler à quelle vitesse ? Quelles options souhaiteriez-vous avoir ?”. La problématique est similaire pour le prix d’un projet web.

Illustration des éléments de calcul du coût d'un projet web

Prix d’un projet web : les principaux facteurs de coûts

En effet, le coût d’un projet web peut varier considérablement en fonction de nombreux facteurs, notamment la taille et la complexité du projet, les fonctionnalités requises, la technologie utilisée, le type de prestation que vous souhaitez.

Pour vous aidez à vous repérer, voici quelques-uns des principaux facteurs qui influencent le prix d’un projet web :

#1 – le nombre et la complexité des fonctionnalités : un site web simple avec des fonctionnalités de base coûtera moins cher qu’un projet avec de très nombreuses fonctionnalités, voire des fonctionnalités complexes (intégrations de solutions externes, algorithmes et calculs, automatisation, …). Attention, le nombre de fonctionnalités souhaitées et la complexité d’un projet ne sont pas toujours corrélées, parfois la majeure complexité d’un projet peut résider dans une seule tâche… Il s’agit donc de faire le maximum d’arbitrage entre coût, pertinence de chaque fonctionnalité et complexité.

#2 – design : un design personnalisé, des animations complexes et d’autres éléments graphiques peuvent aussi augmenter le coût du projet. Au contraire, l’usage de template ou de bibliothèque de composants peuvent permettre des économies de temps et de coût. Au-delà, une recherche en termes UX (user experience) peut aussi alourdir la facture !

#3 – la technologie et/ou la plateforme : le choix de la technologie (par exemple, les langages de programmation, les frameworks, les CMS) et la plateforme sur laquelle le site sera construit influencent évidemment le coût. Par exemple, la plupart des développeurs web savent que développer en Java est souvent plus cher que développer en PHP… (je ne vais pas me faire des amis).

#4 – l’hébergement et l’infrastructure : les coûts d’hébergement, de serveurs et d’infrastructure peuvent varier en fonction des besoins de votre projet.

#5 – La prestation attendue : le coût du développement peut varier d’un prestataire à l’autre. Un freelance vous coûtera moins cher qu’une société (comme la nôtre) mais vous n’aurez pas le même service. Un freelance ne sera pas forcément disponible s’il a un autre contrat par exemple. Le choix entre une approche en régie (obligation de moyen) et une approche au forfait (obligation de résultat) influence aussi les coûts car tout prestataire prévoit une part de risque lorsqu’il s’engage sur un coût forfaitaire.

#6 – La maintenance et le support : n’oubliez pas de prendre en compte les coûts de maintenance continue, de mises à jour de sécurité et de support après le lancement du site.

Le prix d’un projet web peut donc varier considérablement. Avant de commencer votre projet, nous vous recommandons vivement de demander des propositions à plusieurs prestataires et de comparer leurs offres en fonction de vos besoins.

Ordres de grandeur du prix d’un projet web développé par TheCodingMachine

Si on devait être parfaitement sincère, parfois, il y a un décalage entre les attentes des clients et le budget qui est en face, refaire Facebook pour 20.000 euros n’est pas raisonnable ! Même si j’admet volontiers que de très bons outils accessibles quasi gratuitement peuvent donner un résultat très correct. C’est le cas de Webflow pour un petit site vitrine par exemple.

Maintenant, on peut vous donner des ordres de grandeurs de ce que nous faisons régulièrement, comme ça, vous n’aurez pas de surprise :

#1 – un site institutionnel avec des fonctionnalités spécifiques va vous coûter chez TheCodingMachine au minimum 20.000 / 30.000 euros pour avoir un design sur-mesure et des contenus bien adaptés au SEO. Nous nous positionnons sur ce type de prestations lorsqu’il a des enjeux techniques comme l’intégration avec un extranet par exemple.

#2 – une plateforme web ou une application métier de type MVP va démarrer dans les 50.000 / 60.000 euros. Cela représente une équipe de deux ou trois qui va travailler quelques mois à travers, des ateliers de conception, du design, de la mise en place de l’architecture, le développement, la recette et la garantie. Pour en savoir plus sur les plateformes, nous vous recommandons cet article.

Pour un projet plus important, on va se situer entre 80.000 / 150.000 et il n’y pas vraiment de limite. Par exemple, un de nos projets mobilise plus de 20 personnes à temps plein depuis 3 ans…

Quelques conseils pour optimiser le prix d’un projet web !

#1 – Trouvez la substantifique moëlle de votre business : Sachez quelle est votre proposition de valeur ! Si vous n’aviez qu’une seule fonctionnalité à proposer dans votre plateforme, ce serait laquelle ? Est-ce que vous vous sentez capable de la vendre sans rien autour ?

#2 – Ne cherchez pas forcément le moins disant parmi vos prestataires. Un mauvais projet, c’est comme un mauvais recrutement, cela vous coûte le salaire mais surtout le temps que vous y passez !

#3 – Investissez-vous. Plus vous aurez préparé votre projet web, plus vous réduisez le risque et l’incertitude pour votre prestataire chargé du développement… donc plus vous réduisez le prix. Il s’agit d’étudier la concurrence, de réfléchir à la manière dont vous souhaitez que votre plateforme web fonctionne ou de savoir de quels types de design vous souhaitez vous inspirer.

Pour conclure

Difficile d’estimer le prix d’un projet web sans en discuter avec vous. Il y a beaucoup de facteurs à prendre en compte et même si je suis toujours assez surpris de voir des entrepreneurs qui souhaitent investir dans leur business moins que le prix d’une voiture (alors que l’on sait très bien qu’une voiture ne peut rien rapporter…), il est possible d’être malin.

Il ne faut pas non plus rester scotché sur un prix, il faut avancer ! Commencer par une phase de conception avec des ateliers ne vous coûtera pas forcément très cher mais vous permettra de vous mettre en route. En plus, en chemin, vous trouverez peut-être des économies.

Maintenant, si vous souhaitez avoir une estimation personnalisée, n’hésitez pas à nous contacter !

Dette technique, comment l’évaluer et s’en débarrasser ?

Posted on 5 décembre 202316 janvier 2024 by TheCodM

Comme une mauvaise herbe, la dette technique peut s’immiscer dans le jardin de votre projet… Elle se cache et s’épanouit dès les premiers rayons de soleil. Elle est là parce que les décisions techniques ont été trop rapides ou que le projet a évolué trop vite. Des décisions qui étaient raisonnables et censées en début de projet peuvent ne plus fonctionner suite à l’évolution des besoins au fil du temps.

La dette technique est à l’origine de bugs ou de régressions. Elle augmente la complexité du code. Non maîtrisée, elle finit par ralentir le développement, accroître les coûts et peut rendre un système difficile à maintenir.

Pourtant, rien de grave ! La dette technique est souvent normale. Comme pour un jardin, un peu de travail et on enlève ces mauvaises herbes.

Evaluer la dette technique

L’évaluation de la dette technique d’un projet web comprend quelques étape simples pour comprendre la qualité du code, la maintenabilité du projet et les risques potentiels. Petit plan d’actions pour maintenir votre projet en forme :

#1 – Examiner le code source : passez en revue le code source du projet pour identifier des signes de dette technique, tels que des violations de bonnes pratiques de programmation, des sections de code mal structurées, des duplications inutiles, des commentaires obsolètes, etc.

#2 – Analyser les performances : utilisez des outils de profilage et de mesure des performances pour identifier les zones du code qui sont lentes ou gourmandes en ressources.

#3 – Analyser la sécurité : effectuez une analyse de sécurité pour identifier les vulnérabilités potentielles, les failles de sécurité et les risques liés à la sécurité du projet.

#4 – Évaluer la complexité : mesurez la complexité du code en utilisant des métriques telles que la complexité cyclomatique, le couplage, la cohésion, etc.

#5 – Vérifier l’automatisation : assurez-vous que le projet dispose d’une suite de tests automatisés adéquate. L’absence de tests automatisés peut entraîner des erreurs non détectées et des problèmes de qualité.

#6 – Identifier les dépendances obsolètes : recherchez les bibliothèques, les frameworks ou les composants logiciels obsolètes qui ne sont plus pris en charge. Ces dépendances peuvent poser des problèmes de sécurité et de compatibilité.

#7 – Utiliser des outils d’analyse statique : des outils d’analyse statique du code, comme par exemple PHP Stan, peuvent aider à identifier automatiquement des problèmes de dette technique en parcourant le code à la recherche de violations de normes et de bonnes pratiques.

Vous pouvez, en outre, faire l’analyse de l’architecture globale du projet pour voir si elle est bien conçue, vérifier la documentation et aussi collecter les retours d’expérience des développeurs. Les discussions avec les membres de l’équipe sont souvent très instructives.

Parfois, il est préférable de solliciter un acteur extérieur, tel que TheCodingMachine, pour un audit technique afin de bénéficier d’une analyse neutre et d’éviter les conflits d’intérêts au sein de vos équipes.

Éradiquer la dette technique

Pour se débarrasser de la dette technique, voici quelques étapes importantes à suivre :

#1 – Priorisation : une fois que vous avez une liste d’éléments de dette technique, hiérarchisez-les en fonction de leur impact sur le projet. Concentrez-vous sur les éléments qui ont le plus grand impact négatif.

#2 – Planification : élaborez un plan pour résoudre la dette technique. Cela peut inclure la réécriture de code, la mise à jour de la documentation, la résolution de problèmes de sécurité, etc. Assurez-vous de fixer des échéances réalistes !

#3 – Communication : informez les parties prenantes du projet, y compris les membres de l’équipe et les clients, des efforts déployés pour résoudre la dette technique. Assurez-vous bien qu’ils comprennent l’importance de cette démarche.

#4 – Tests et validation : après avoir résolu la dette technique, n’oubliez pas d’effectuer des tests approfondis pour vous assurer que les problèmes ont été résolus et que le code est de qualité.

Se débarrasser de la dette technique demande du temps, des ressources et un engagement continu, mais cela améliore la qualité, la stabilité et les coûts de vos projets à long terme. Parfois, les chefs de projets ou les développeurs culpabilisent de cette dette technique qui s’est installée. Mais ce n’est pas nécessairement de leur faute. Les plannings tendus, l’évolution du projet au fil du temps sont bien souvent les premiers coupables.

Pour aller plus loin et éviter la réapparition de la dette technique, mettez en place des pratiques de développement de logiciels plus rigoureuses, encouragez la documentation, assurez-vous que l’équipe suit les meilleures pratiques et allouez du temps pour la maintenance continue. Assurez-vous que l’équipe est consciente de l’importance de maintenir un code propre. Bon jardinage à tous !

https://www.linkedin.com/in/kevin-nguyen-2146514/, si vous souhaitez en parler avec moi !

Sécurité web : 5 failles informatiques à éviter

Posted on 21 avril 2023 by TheCodM

Fonctionnalités, design, performances, vous avez pensé à tout pour votre projet web…sauf peut-être à la sécurité !

Pourtant, qu’il s’agisse d’un blog, d’un site de vente en ligne, d’un intranet, d’un extranet ou d’une application, les failles de sécurité web peuvent coûter cher !

Pour éviter que ces vulnérabilités ne mettent à mal vos projets, découvrez les 5 principales failles de sécurité web et comment les empêcher.

Pourquoi s’intéresser à la sécurité web ?

La sécurité web vise à protéger tous les aspects d’un site : ses fonctionnalités, ses données, ses fichiers, son code source, et ainsi à éviter les risques d’une cyberattaque.

Or, les particuliers, les administrations, les entreprises, les associations, tous peuvent être victimes de hackers avec des conséquences parfois catastrophiques :

Vol et divulgation de données (mots de passe, adresses électroniques, numéro de sécurité sociale et de cartes bancaires),
Indisponibilité des services,
Perte de confiance des utilisateurs,
Atteinte à leur réputation,
Déclin de leur activité, voire faillite.

La sécurité web est donc un enjeu majeur pour toutes les entreprises.

Quelles sont les 5 failles de sécurité web les plus fréquentes ?

Dans son rapport de 2021, OWASP (Open Web Application Security Project), communauté en ligne qui teste des centaines d’entreprises et de sites pour connaître les failles de sécurité web les plus répandues, a répertorié les 10 principaux risques de sécurité des applications web.

1- Broken Access Control

Le contrôle d’accès permet d’encadrer les autorisations d’accès aux ressources pour les différents types d’utilisateurs. En cas de vulnérabilité informatique, un utilisateur non autorisé peut accéder à des informations ou faire certaines actions.

Comment empêcher cette faille de sécurité web ?

À l’exception des ressources publiques, refuser l’accès à une ressource par défaut.
Désactiver la liste des répertoires du serveur web et vérifier que les métadonnées des fichiers (par exemple, .git) et les fichiers de sauvegarde ne sont pas présents dans la racine de votre application ou site web.
Enregistrer les échecs de contrôle d’accès répétés, et alerter les administrateurs le cas échéant.

2- Cryptographic Failures

Il s’agit de défaillances liées à la cryptographie ou à son absence : des données sensibles ne sont pas correctement protégées et peuvent donc être volées et divulguées.

Pour chaque projet web, il faut déterminer les besoins de protection des données, notamment pour les données sensibles et personnelles qui nécessitent une protection supplémentaire et peuvent relever de réglementation particulière (RGPD par exemple).

Comment l’éviter ?

Classer les données traitées par l’application et identifier les données sensibles en fonction des réglementations en vigueur ou des besoins de l’entreprise.
Ne pas stocker de données sensibles inutilement.
Chiffrer toutes les données en transit avec des protocoles sécurisés tels que TLS. Appliquer le chiffrement à l’aide de directives telles que HTTP Strict Transport Security (HSTS).
Désactiver la mise en cache pour les réponses contenant des données sensibles.

3- Injection

Les données fournies par l’utilisateur ne sont pas validées ou filtrées par l’application. Ces données hostiles sont utilisées directement, sans aucune vérification.

L’injection SQL est l’injection la plus courante, mais il peut également y avoir des injections de commandes LDAP.

Comment éviter ce risque ?

Utiliser ORM (Object-Relational Mapping) correctement.
Échapper les caractères spéciaux pour toute requête dynamique résiduelle.
Utiliser une validation positive d’entrée côté serveur.

4- Insecure Design

C’est un nouveau risque de sécurité web dans le rapport OWASP de 2021.

Il s’agit de défauts de conception et d’architecture : présence d’un processus non sécurisé, message d’erreur avec des informations sensibles, stockage non protégé d’informations d’identification, etc.

Comment l’empêcher ?

Faire valider votre choix d’architecture par un professionnel pour vous aider à évaluer et à concevoir des contrôles liés à la sécurité et à la confidentialité.
Utiliser une bibliothèque de modèles de conception sécurisés.
Intégrer des contrôles de sécurité dans les user stories.
Mettre en place des contrôles de plausibilité à chaque niveau de votre application (du frontend au backend).

5- Security Misconfiguration

Les données sont mal sécurisées à différentes parties de l’application, car il y a une mauvaise configuration.

Votre application peut par exemple être vulnérable du fait de :

L’absence de renforcement approprié de la sécurité sur une partie de la pile d’applications ou des services externes.
La présence de fonctionnalités inutiles.
Comptes par défaut et de mots de passe activés et inchangés.

Comment éviter cette faille informatique ?

Un processus de durcissement automatisé permet de déployer rapidement et facilement un autre environnement correctement verrouillé.
Supprimer ou ne pas installer les fonctionnalités, frameworks ou packages inutilisés ou inutiles.
Mettre en œuvre une architecture d’application segmentée.
Mettre en place un processus automatisé pour vérifier l’efficacité des configurations et des paramètres dans tous les environnements.

À côté de 5 principales failles, d’autres risques pour la sécurité web existent. Pour savoir comment les empêcher, découvrez notre vidéo Web Security.

Informatique quantique : opportunités et challenges

Posted on 19 avril 202321 avril 2023 by TheCodM

Avec sa puissance de calcul, l’informatique quantique promet de révolutionner de nombreux domaines. Médecine, finance, logistique, cybersécurité, le champ d’application de l’informatique quantique est vaste, mais de nombreux défis techniques restent à relever pour développer un ordinateur quantique opérationnel.

Quelles applications pour l’informatique quantique ?

De nombreux domaines pourraient profiter des capacités de calcul des ordinateurs quantiques :

La logistique : l’informatique quantique pourrait être utilisée pour résoudre des problèmes complexes d’optimisation et de planification des chaînes d’approvisionnement.

La recherche médicale et scientifique : les technologies quantiques pourraient améliorer les simulations des systèmes biologiques, ce qui permettrait de mieux comprendre les mécanismes de certaines maladies et de trouver des traitements plus efficaces. Les algorithmes quantiques pourraient également être utilisés pour analyser des données complexes comme les images médicales et accélérer ainsi la recherche de nouveaux médicaments.

La finance : les ordinateurs quantiques pourraient aider à optimiser les placements, à prédire les risques financiers et à analyser les données des marchés en temps réel.

La cybersécurité : grâce à ses capacités de chiffrement et de déchiffrement des données, l’informatique quantique peut aider à protéger les données des entreprises et des administrations, à renforcer la sécurité web et à lutter contre les cyberattaques.

Toutefois, le décryptage des données par un ordinateur quantique peut également être un risque pour la sécurité. En effet, l’algorithme Shor est un algorithme quantique qui permet la factorisation des très grands nombres en un temps record. Or, les méthodes de cryptage actuelles, et notamment le procédé de chiffrement RSA actuellement utilisé dans de nombreux protocoles sur Internet, reposent sur la difficulté, pour les technologies actuelles, de factoriser de grands nombres.

Si les technologies quantiques peuvent être un risque pour la cybersécurité, elles pourront en même temps être une solution pour l’améliorer, en permettant de crypter les données et les transactions avec des systèmes de cryptographie plus robustes et plus sécurisés que ceux actuellement en vigueur.

L’intelligence artificielle : l’informatique quantique pourrait être utilisée pour entraîner des modèles d’apprentissage automatique plus rapidement, avec plus de données et pour résoudre des problèmes plus complexes, comme la reconnaissance d’images.

Les obstacles à surmonter pour développer un ordinateur quantique fonctionnel

Pour qu’un ordinateur quantique puisse être effectivement développé et utilisé, plusieurs défis doivent encore être relevés, parmi lesquels :

La stabilité des qubits : les qubits sont très sensibles à leur environnement et peuvent être perturbés par celui-ci (bruit, chaleur, champs magnétiques, interactions avec d’autres qubits, etc.). Or, les qubits doivent être stables pour stocker et manipuler des informations pendant une période de temps suffisamment longue pour effectuer des opérations de calcul. Il faut donc réussir à maintenir un qubit dans son état quantique en augmentant le temps de cohérence (durée pendant laquelle l’objet est dans son état quantique) et en évitant la décohérence quantique.

La réduction des erreurs de calcul : les ordinateurs quantiques peuvent produire des erreurs de calcul qui nuisent à la précision de leurs résultats. Cela est dû en partie à l’instabilité des qubits.

La gestion de la température : les ordinateurs quantiques génèrent beaucoup de chaleur en raison de la manipulation de l’information quantique. En parallèle, les qubits doivent être maintenus à des températures extrêmement basses pour rester stables et fonctionner, ce qui nécessite des systèmes de refroidissement spécifiques et coûteux.

La programmation des ordinateurs quantiques : elle est très différente de la programmation d’un ordinateur classique. Elle nécessite des connaissances en physique quantique.

Le coût de la recherche quantique : pour se développer, la recherche dans le domaine de l’informatique quantique a besoin d’équipements de pointe qui sont très coûteux et donc de moyens financiers importants.

Pour en savoir plus sur l’informatique quantique, découvrez notre vidéo sur les différents principes de la physique quantique et les propriétés de l’ordinateur quantique.

Serverless, 4 questions sur l’informatique sans serveur

Posted on 4 avril 20236 février 2024 by TheCodM

Développer des applications sans avoir à gérer les serveurs, c’est possible avec l’informatique sans serveur, ou approche Serverless.

En quoi consiste ce mode de développement ? Quels sont ses atouts et ses limites ?

Découvrez l’essentiel à retenir sur l’informatique sans serveur.

Informatique sans serveur, qu’est-ce que c’est ?

Avec le Serverless, les développeurs web n’ont plus à s’occuper de la gestion des serveurs. Les serveurs sont toujours là pour faire fonctionner les applications, mais ils sont gérés par un fournisseur de services web, un provider, et non plus par les développeurs.

Le fournisseur de services alloue ensuite automatiquement les ressources nécessaires à l’exécution de l’application et les utilisateurs paient uniquement pour les ressources utilisées.

Quels sont les avantages de l’informatique sans serveur ?

Que ce soit pour les développeurs ou pour les entreprises, le Serverless a plusieurs avantages :

Réduction des coûts de développement et d’exploitation : Les fournisseurs Serverless proposent une facturation proportionnelle à l’usage du service et non en fonction des capacités d’un serveur acheté à l’avance. Cela permet de réduire les coûts d’infrastructure pour les entreprises et d’éviter de gaspiller une partie de l’espace serveur acheté.

Optimisation du temps de développement : En permettant aux développeurs de se concentrer sur l’écriture du code plutôt que sur la gestion et la maintenance de l’infrastructure, l’informatique sans serveur permet de réduire le temps de développement et donc le time to market des applications.

Amélioration de la scalabilité : Les services Serverless évoluent de manière dynamique en fonction de l’afflux d’utilisateurs. Il n’y a donc pas de rupture de services. Les applications sans serveur peuvent être facilement mises à l’échelle et évoluer pour répondre aux besoins des entreprises.

Quelles sont les limites du Serverless ?

Bien que l’informatique sans serveur offre de nombreux avantages, il présente également certaines limites à considérer avant de faire le choix du Serverless :

Un temps d’exécution limité : Les fonctions sans serveur sont limitées dans le temps d’exécution et les ressources disponibles.

Chaque fonction est sans état, stateless function. La fonction s’exécute par conséquent avec un contexte nouveau lors de chaque requête.

Le Cold Start, ou démarrages à froid : Quand une fonction n’est pas appelée, elle ne tourne pas. Le fournisseur la désactive afin d’économiser de l’énergie. Si ces fonctions éphémères, qui s’exécutent uniquement lorsque cela est utile, vont dans le sens des principes du Green IT en limitant la consommation d’énergie, elles ont pour inconvénient d’ajouter une latence lors du lancement de la fonction. C’est pourquoi, les premières requêtes sont moins performantes.

Une dépendance aux fournisseurs de services Serverless : En utilisant l’informatique sans serveur, les entreprises et les développeurs n’ont plus la main sur les serveurs. Ils ne peuvent pas changer la configuration PHP, ni personnaliser le serveur. Ils dépendent de ce que proposent les fournisseurs de services.

Des coûts variables difficiles à prévoir : L’informatique sans serveur peut permettre de réduire les coûts d’infrastructure. Toutefois, avec le système de la facturation en fonction de la consommation des ressources, les coûts peuvent être très variables et sont difficiles à prévoir pour les entreprises.

Quels sont les fournisseurs de services Serverless ?

Les fournisseurs Serverless mettent à disposition une plateforme qui permet aux développeurs d’intégrer facilement des fonctions à leur application. Ils fournissent une plateforme FaaS (Function-as-a-Service) qui permet de déployer et d’exécuter le code sans avoir à assurer la maintenance de l’infrastructure. Les fournisseurs de services s’occupent également de la gestion et de la mise à l’échelle des serveurs et des éventuels correctifs et mises à jour de sécurité des serveurs.

Parmi les fournisseurs proposant des services Serverless :

Amazon Web Services (AWS) avec AWS Lambda
Microsoft Azure avec Azure Functions
Google Cloud Platform avec Google Cloud Functions

Vous souhaitez développer une application avec l’informatique sans serveur ? Découvrez comment créer une API Serverless dans notre vidéo.

Éco-conception web, 20 bonnes pratiques à adopter

Posted on 4 avril 20234 avril 2023 by TheCodM

Créer un site web, une application ou un logiciel éco-responsable, tel est l’objectif de l’éco-conception web.

De plus en plus répandue, cette pratique permet de réduire l’impact environnemental des projets numériques tout en développant des sites performants qui offrent une expérience utilisateur de qualité. Voici 20 bonnes pratiques à adopter pour optimiser l’empreinte écologique des projets IT tout au long de leur cycle de vie.

L’éco-conception web de la phase des spécifications à la mise en production d’un projet IT

Dès la définition d’un projet de création d’un site ou d’une application, les bonnes pratiques d’éco-conception web s’appliquent :

1- Éliminer les fonctionnalités non utilisées : cela permet d’alléger le poids des applications.

2- Quantifier précisément le besoin : l’objectif est d’éviter les surdimensionnements inutiles, par exemple en optimisant la taille des images.

3- Optimiser le parcours utilisateur en diminuant le nombre d’actions et en réduisant les temps de réponse. En plus de limiter l’empreinte environnementale, cela permet de charger moins de pages et d’offrir une meilleure expérience aux utilisateurs avec un site plus rapide.

4- Privilégier un design simple et épuré en évitant les images et les vidéos. Lorsque celles-ci sont indispensables, leur taille doit être optimisée.

5- Mettre en cache les données.

6- Limiter le nombre de requêtes HTTP.

7- Stocker les données statiques localement en utilisant le localStorage lorsque c’est possible. Cela évite de recharger les mêmes éléments à chaque nouvelle navigation.

8- Choisir un format de données adapté pour éviter un gaspillage de mémoire et limiter les problèmes de performances du site.

9- Assurer la compatibilité de l’application créée avec les anciens appareils et logiciels : l’objectif est de respecter les principes du Green IT et de ne pas obliger les utilisateurs à renouveler leur équipement.

10- Utiliser un cache HTTP.

11- Ajouter des entêtes Expires ou Cache-Control : elles permettent de définir la durée pendant laquelle un navigateur doit conserver une ressource dans son cache.

12- Réduire les logs serveurs.

13- Mettre en place une politique d’expiration et de suppression des données : de nombreux systèmes de gestion de bases de données permettent de définir une durée de vie des données. Au-delà de cette durée, les données expirées sont purgées et effacées définitivement. En plus de suivre la démarche d’éco-conception web, le fait de ne pas stocker indéfiniment des données permet de respecter le RGPD.

14- Opter pour un hébergement écologique : dans une démarche d’éco-conception web, le choix de l’hébergeur est une étape importante. Certains sont un peu plus verts que d’autres avec, par exemple, des serveurs alimentés par des énergies renouvelables ou la mise en place de politique de compensation carbone pour réduire leur impact environnemental.

Utilisation, maintenance et fin de vie des projets web éco-conçus

L’éco-conception web continue de s’appliquer une fois le projet développé et produit. Ainsi, pour éviter d’utiliser des ressources inutilement, certaines mesures éco-responsables peuvent être prises :

15- Limiter les e-mails lourds, nombreux et redondants.

16- Éviter la lecture automatique des vidéos et des sons.

17- Entretenir son site régulièrement : un entretien régulier permet de garantir le bon fonctionnement du site, d’optimiser sa performance et d’améliorer l’expérience utilisateur.

18- Éviter les redirections : elles dégradent le temps de réponse et consomment des ressources inutilement, ce qui est contraire à l’éco-conception web.

19- Mettre en place une politique de suppression des contenus et des articles, notamment ceux qui ne sont plus visités ou sont très anciens, afin de libérer de l’espace pour de nouveaux contenus.

20- Établir un plan de fin de vie du site lorsque ce dernier n’est plus utilisé.

En plus de ces pratiques éco-responsables, d’autres moyens existent pour réduire l’impact du numérique et sont à découvrir dans notre vidéo sur le green IT et l’éco-conception web.

Comprendre en 5 minutes les API

Posted on 3 avril 20236 février 2024 by TheCodM

Une API (Application Programming Interface) est un ensemble normalisé de classes, de méthodes, de fonctions et de constantes qui sert de façade par laquelle un logiciel offre des services à d’autres logiciels, afin d’échanger des données et des fonctionnalités.

Types d’API

Il existe quatre principaux types d’API couramment employés.

API publiques :

Une API publique (ou API externe), est une API ouverte pour tous les développeurs, qui propose l’accès à ses données et ses services sous forme de libre-service. Cela suppose généralement une authentification et une autorisation modérées.

API privées :

Une API privée (ou API interne), est une API créée et utilisée uniquement au sein de l’entreprise. Ce type d’API n’est pas accessible pour des développeurs externes.

API partenaires :

Une API partenaire est une API qui est partagée uniquement à une liste de développeurs ou d’entreprises bien définie. Les droits d’accès à l’API sont de fait plus restrictifs que ceux d’une API publique.

API composites :

Une API composite est une combinaison de plusieurs API. Cela permet de grouper plusieurs requêtes en un seul appel API. Cette réduction du nombre d’appels améliore la vitesse et les performances de l’API. Ce type d’API est généralement utilisé dans les micro services.

Protocoles et architectures d’API

Il existe plusieurs protocoles et architectures d’API pour permettre cet échange de données et de fonctionnalités. Ils sont régis par des règles, des structures, et des contraintes différentes.

REST

L’architecture REST (Representational State Transfer) est un style d’architecture qui suit plusieurs principes fondamentaux:

Client-Serveur : les responsabilités sont séparées entre le client et le serveur. Le client envoie les requêtes au serveur, et le serveur retourne les réponses au client. Ils doivent être indépendants : un changement sur l’un ne doit pas impacter l’autre.
Stateless : (Sans état) Chaque interaction client-serveur est indépendante. Le serveur ne stocke pas les données des requêtes précédentes.
Cache : Les réponses du serveur peuvent être mises en cache, pour améliorer les performances et éviter d’appeler le serveur pour récupérer des données qui n’évoluent pas ou peu.
Layered : (Système multicouche) Architecture qui permet d’avoir plusieurs serveurs intermédiaires qui peuvent améliorer l’extensibilité du système en mettant en place une répartition de charge et un cache partagé.
Interface uniforme : Le client et le serveur communiquent avec le protocole HTTP, qui possède plusieurs méthodes de communication (GET, POST, PUT, DELETE, …). Chaque requête possède un URI (Uniform Resource Identifier), et renvoie des données sous une forme prédéfinie (JSON, XML, …).

Les API REST sont majoritairement utilisées pour les sites web accessibles au public. Elles permettent d’avoir une communication relativement simple entre le client et le serveur.

Ce sont des API flexibles, qui peuvent s’adapter à différents types de données (même si le JSON est le plus répandu).

SOAP

SOAP (Simple Object Access Protocol) est un protocole d’échange d’informations utilisant le XML (Extensible Markup Language).

Ce protocole définit de façon stricte comment les messages doivent être envoyés, et ce qui doit être inclus dedans. Cela fait de SOAP un protocole plus sécurisé que REST, mais qui le rend en contrepartie plus lourd au niveau du code, et plus compliqué à implémenter de façon générale.

SOAP utilise généralement le protocole HTTP, mais contrairement au REST, il n’est pas restreint à celui-ci, et peut utiliser le SMTP par exemple.

Il est généralement utilisé pour les applications liées au paiement, qui demandent une haute sécurité, ou pour des API internes.

RPC

RPC (Remote Procedural Call) est un protocole qui invoque des actions ou des processus exécutables sur un serveur.

Il peut aussi bien utiliser du JSON (avec le protocole JSON-RPC) ainsi que du XML (avec XML-RPC).

Contrairement aux API REST, le RPC n’accepte que les requêtes de type GET ou POST.

Le RPC se démarque par des payloads plus légers, ce qui améliore nettement les performances des requêtes client-serveur.

Dernièrement, c’est le framework gRPC, développé par Google qui s’est démarqué grâce à toutes ses améliorations apportées au protocole RPC. Il utilise HTTP/2 pour le transport des données, Protobuf (Protocol Buffers) comme format de sérialisation, qui encode les données envoyées et reçues pour minimiser le poids des requêtes, et encore améliorer les performances.

GraphQL

GraphQL est un langage de requête créé par Facebook, qui propose une alternative à REST. Il utilise une architecture basée sur un système de schéma de requêtes typé qui permet d’éviter les problèmes d’over/under-fetching, c’est à dire que le client récupère exactement ce qu’il demande au serveur, sans surplus de données inutiles.

Contrairement aux autres protocoles et architectures d’API, c’est le client qui définit les données à récupérer, et non pas le serveur qui décide quelles données à renvoyer.

Cela permet d’améliorer les performances sur les requêtes faites au serveur en s’assurant qu’il n’y aura pas de surplus d’informations, mais également de s’assurer que les données demandées sont bien existantes, et dans le bon type demandé.

Ce langage possède cependant quelques limitations, comme le fait de ne pas pouvoir gérer facilement l’upload & le download de fichiers. Néanmoins, chez TheCodingMachine nous sommes fans et avons développé notre propre librairie PHP pour aller avec GraphQL : GraphQLite.

Si vous souhaitez aller plus loin dans votre compréhension du secteur et du vocabulaire tech, n’hésitez pas à lire notre : livre blanc « Do you speak technique ? »

Le stress test avec JMeter

Posted on 21 mars 202321 mars 2023 by TheCodM

Outil de stress test open source, JMeter permet de tester et d’optimiser les performances des applications, sites web et serveurs.

Découvrez pourquoi un test de performance est essentiel dans un projet web et comment se déroule un stress test avec JMeter.

Pourquoi effectuer un stress test avec JMeter ?

Application trop lente et/ou qui ne répond pas, les problèmes de performance d’un site, d’une application, d’un logiciel ou d’un serveur peuvent altérer l’expérience utilisateur (UX), l’image de marque et les résultats d’une entreprise.

Réaliser un stress test avec JMeter, ou avec un autre outil, permet d’identifier et de corriger tous les points de vulnérabilité qui vont entraîner des erreurs en cas de forte affluence et d’analyser comment va répondre le système dans ces situations.

Il permet de vérifier la robustesse d’un système, ses capacités de réponse et de gestion des erreurs lorsqu’il est soumis à des conditions où son fonctionnement normal est compromis comme un afflux d’utilisateurs.

Le stress test participe ainsi à l’optimisation des performances d’un site et de l’expérience utilisateur.

Bon à savoir : Un stress test n’est jamais un parfait reflet de la réalité. Il correspond plutôt à un indice de confiance quant à la robustesse du système face à certaines situations.

Les étapes des stress tests

Les stress tests se déroulent en 5 étapes :

1- Définir les scénarios tests : Quelle activité faut-il simuler pour être au plus proche de la réalité ? Quels sont les différents scénarios ?

2- Définir les variables des scénarios : nombre d’utilisateurs, quel scénario commence en premier, etc.

Une démarche itérative doit ensuite être entamée :

3- Exécution des stress tests.

4- Prise des mesures pendant les stress tests et identification, si possible, du facteur limitant.

5- Optimisations sur le facteur limitant identifié : par exemple en réduisant la complexité du code, ou en évitant que les boucles ne fassent trop appel à la base de données et en privilégiant la mise en cache.

Puis, on recommence : lancement des stress tests, mesure pour vérifier qu’il y a bien une évolution sur le facteur limitant identifié, etc.

Les composants d’un stress test avec JMeter

Initialement spécialisé dans les stress tests notamment HTPP, JMeter a développé d’autres capacités de tests sur divers protocoles (FTP, SOAP, EJB, etc.).

Pour un stress test avec JMeter, il faut créer un test plan dans lequel seront définies les principales métriques : les valeurs par défaut, les variables, les enchaînements des Thread Group, etc.

Les Thread Group correspondent à un scénario. Un groupe de Threads est un ensemble d’utilisateurs exécutant le même scénario. Le groupe de Threads indique à JMeter le nombre d’utilisateurs à simuler, le nombre de requêtes que chaque utilisateur doit envoyer et la fréquence à laquelle il doit les envoyer.

Le Sampler : c’est l’objet principal d’un Thread Group. Le sampler correspond à une requête envoyée par JMeter au serveur ou à l’application testé.

Les Controller : en général, les Sampler sont rangés à l’intérieur des Controller. Ces derniers permettent de donner de la logique à leurs éléments enfants en gérant l’ordre de traitement des requêtes dans un Thread.

Les Assertion : permettent de tester le résultat d’une requête et de vérifier le résultat attendu avec le résultat réel de la demande au moment de l’exécution.

Les Timer : définissent des intervalles de temps après chaque requête envoyée d’un même Controller.

Les Config Element : permettent de définir différentes variables.

Les Pre Processors : modifient un Sampler avant qu’il ne soit exécuté.

Les Post Processors : ils sont utilisés pour traiter et extraire les données de réponse du serveur.

Les Listener : ils servent surtout à modifier, extraire et sauvegarder les données. Il est ensuite possible de choisir de les présenter dans un tableau, un graphique ou un arbre.

Quand le stress test avec JMeter est terminé, un rapport complet est généré permettant d’avoir les informations utiles pour optimiser les performances de l’application ou du site.

Besoin d’exemples ou de plus de précisions sur le déroulé d’un stress test avec JMeter ? Regardez notre vidéo pour un stress test avec JMeter sans stress.

Code review : 4 étapes pour une revue de PR efficace

Posted on 8 mars 202323 mars 2023 by TheCodM

Étape incontournable dans le développement d’un logiciel ou d’une fonctionnalité, la revue de PR, pour Pull Request (GitLab) ou Merge Request (GitHub et Bitbucket), permet de s’assurer de la qualité du code à intégrer.

Mais pour que ce travail de revue de PR soit efficace, plusieurs étapes sont nécessaires.

1- Créer une branche locale

Lors de la création d’un feature et d’une branche en local, il faut choisir avec soin la branche initiale d’où est tirée cette nouvelle branche.

Il peut s’agir de la branche develop pour une fonctionnalité, mais il est également possible de tirer une branche depuis master pour un hotfix par exemple.

Il faut par contre éviter de tirer des branches depuis des branches qui ne sont pas encore mergées dans la branche principale. Cela risque de créer des difficultés qui seront ingérables avec le temps.

2. Développer la fonctionnalité ou le correctif

Après avoir correctement créé une branche, vous pouvez développer votre code. Pour une meilleure fluidité dans votre travail et dans celui du reviewer, il est important de commiter régulièrement votre code. Cela permet de comparer plus facilement les différentes versions de commits sur les PR, de voir ce qui s’est passé entre deux changements et cela facilite les potentiels revert.

Une fois ces développements terminés, le code peut être rapatrié sur la branche principale. La PR peut être ouverte.

3. Ouvrir la PR

Pour rapatrier le code sur la branche principale, il faut ouvrir la PR :

On push la branche sur le dépôt : Le CLI peut directement afficher un lien d’ouverture (ou de consultation) de la PR associée.

Lors de l’ouverture de la PR sur GitLab, on a le choix de la branche cible (branche sur laquelle on rapatrie la branche sur laquelle on travaille). Il est important de ne pas se tromper et d’ouvrir la PR sur la bonne branche.

Il est possible d’ouvrir une PR même si le développement n’est pas terminé, avec le statut Draft. Il ne faut pas hésiter à utiliser ce statut qui va permettre à tout le monde de voir que le développement est en cours, avec les commits, les pushs, etc. À ce stade, un reviewer peut être affecté pour commencer la revue de PR et faire des retours au fil de l’eau.

Il faut essayer de choisir un nom de PR pertinent et explicite. Le nom par défaut peut ne pas être forcément lisible.

Il ne faut pas hésiter à ajouter des commentaires pour préciser au reviewer les points sur lesquels il y a de potentiels manquements, sur lesquels on a des doutes ou si l’on souhaite lui donner une marche à suivre pour la revue de PR.

Il faut vérifier que notre pipeline est passée, car il y a de fortes probabilités que celle-ci se déclenche au moment où on push notre branche. GitLab va nous permettre de voir si notre pipeline est verte ou rouge.

Il faut également s’assurer qu’il n’y a pas de conflits avec la branche cible, car celle-ci a pu avancer plus vite que nous. Aucune PR ne doit rester avec des conflits, il faut les résoudre en local ou avec GitLab.

Afin de prendre du recul sur son travail, on relit son code et sa PR à tête reposée.

Une fois qu’on est prêt, on peut assigner le reviewer. Le reviewer n’est pas forcément une personne plus compétente techniquement. C’est quelqu’un qui va avoir un regard externe et neutre et qui va pouvoir détecter les erreurs par expérience, lors de la revue de PR.

4. La revue de PR par un reviewer

La tâche du reviewer est de :

Lire et étudier la PR,

Apporter des commentaires ou des ajustements à transmettre à l’assignee (l’auteur de la PR),

Faire une revue de PR et de code après les changements apportés,

Approuver la PR si le code est clean et que la fonctionnalité est bonne,

Merger la PR le plus rapidement possible afin d’éviter d’empiler les PR et d’avoir plusieurs PR ouvertes.