Savoir-faire et technologie

<p>Certaines personnes se fâchent devant les mots <i>processus</i> ou <i>normes</i>, mais moi, et d’autres comme moi, nous avons tendance à apprécier une structure claire. Les processus sont partout autour de nous : à la maison, au travail et partout ailleurs. Même les enfants sont exposés aux processus et aux normes dès leur plus jeune âge. Que cela nous plaise ou non, nous suivons tous des processus dans notre vie quotidienne.</p><p>Je crois que les processus sont le ciment qui maintient tout ensemble, et que les normes sont ce qui nous aide tous à atteindre un objectif commun avec un haut niveau de qualité. L’expérience nous a montré que nous avons beaucoup plus de succès lorsque nous avons de formidables processus en place avec une pincée de normes. Voici quelques exemples que j’aimerais partager.</p><h3>Documenter les processus et les normes à la vue de tous</h3><p>Tout au long de ma carrière, j’ai vu des processus, des normes et des politiques documentés dans divers outils, et l’uniformité semble être la formule gagnante. Vous pouvez placer vos normes méticuleusement documentées sur Internet, les afficher au mur dans votre bureau, ou même <a href="https://developer.amazon.com/fr/blogs/alexa/post/2b4d2dc0-22d4-4e41-a51e-436adc687d7f/create-an-alexa-skill-for-your-organization-in-minutes-with-alexa-for-business-blueprints">créer des <i>skills</i> Alexa</a> pour votre organisation afin d’aider les employés à les trouver. Mais quoi que vous fassiez, assurez-vous simplement que les gens savent où les trouver et que cela demeure cohérent.</p><h3>Cohérence du projet</h3><p>Nous avons réalisé de nombreux projets au fil des ans, et bien que chaque projet soit différent, les processus et les normes ont toujours joué un rôle important dans le succès de chacun. Qu’il s’agisse du transfert en provenance des ventes, de la collaboration produit et production, du passage de la production à l’assurance de la qualité, un bon processus assure la cohérence de tous nos projets et aide tous les membres de l’équipe à savoir ce qui doit être fait et comment le faire.</p><h3>Réutilisabilité</h3><p>La réutilisation de code doit se faire avec discernement. La question que j’aime garder à l’esprit est la suivante : quelqu’un d’autre peut-il bénéficier de cette fonctionnalité, que ce soit dans mon entreprise ou dans le monde de l’open source ? Si la réponse est oui, vous devriez envisager de concevoir la fonction pour qu’elle soit réutilisable. La création de petits composants réutilisables, au code simple et partageable, vous permettra de :</p><ul> <li>fournir des estimations plus basses et plus précises pour les fonctionnalités communes ;</li> <li>réutiliser un code de qualité production qui a été rigoureusement testé ;</li> <li>consacrer vos efforts à une logique métier complexe qui ne peut pas être réutilisée.</li></ul><h3>Revues de code</h3><p>Les revues de code ont une valeur non négligeable, si vous les utilisez correctement. Chaque fonctionnalité que nous créons doit passer par le processus de révision du code par des pairs, ce qui nous aide à écrire un code plus propre et plus homogène, à réduire les bogues et à partager les connaissances entre tous les domaines du développement. Mon collègue, Claude Houle, a écrit un super article sur l’<a href="https://www.spiria.com/fr/blogue/methodes-et-bonnes-pratiques/la-revue-de-code-tout-simplement/">importance de la revue de code</a> qui vaut la peine d’être lu.</p><h3>Tests unitaires</h3><p>Les tests unitaires ne sont peut-être pas envisageables dans tous les projets, mais leur utilisation dans les bonnes circonstances a une valeur indéniable. Les tests unitaires peuvent aider à réduire le nombre de bogues pendant le développement, ce qui augmente efficacement votre capacité de production. L’ajout de tests unitaires pour une logique métier essentielle, pour des fonctionnalités complexes ou lorsqu’un problème de qualité est détecté devrait renforcer votre confiance à chaque déploiement. Si vous souhaitez en savoir un peu plus sur ces tests, n’hésitez pas à lire l’<a href="https://www.spiria.com/fr/blogue/applications-web/comprendre-la-difference-entre-un-test-unitaire-et-un-test-dintegration/">article de blogue</a> d’Anthony Giretti.</p><h3>Scalabilité</h3><p>La montée en charge est un aspect que vous ne devez pas ignorer si vous voulez que les utilisateurs aient la meilleure expérience possible avec votre site Web ou application mobile. Que vous attendiez 200 utilisateurs simultanés sur votre plate-forme ou 10 000 nouvelles inscriptions après un lancement marketing, essayez de vous poser les questions suivantes :</p><ul> <li>Cette fonctionnalité peut-elle se mettre à l’échelle avec de petits et grands ensembles de données ?</li> <li>Mes pages se chargeront-elles rapidement pour tous les utilisateurs (nouveaux et anciens) quelle que soit la quantité de données en jeu ?</li> <li>Est-ce que j’utilise des techniques comme la mise en cache, et est-ce que je me demande quand ces techniques pourraient compromettre la fonctionnalité ou les résultats escomptés ?</li></ul><h2>Parlez plus fort (lorsque tout le monde écoute)</h2><p>Je pourrais parler sans arrêt des différents normes et processus que nous utilisons quotidiennement chez Spiria, mais mon but était de partager quelques idées qui vous aideront à vous interroger et à voir comment vous pouvez faire une différence. Si vous avez l’impression que quelque chose est cassé, examinez vos processus et vos normes et tentez de faire une proposition d’amélioration.</p><p>Une chose que je garde toujours à l’esprit, c’est que nous ne pouvons pas faire porter l’échec sur un manque de processus. Nous devons plutôt travailler à la création, à la mise à jour et au partage des informations qui nous aident tous à progresser sur la voie du succès.</p><p>Je suis dans le camp du « verre est à moitié plein » et avec cela à l’esprit, tout le monde et chaque processus sont susceptibles de s’améliorer. Cela fait partie de la croissance, qu’elle soit personnelle, professionnelle ou celle de l’entreprise. Quand on arrête de pointer du doigt et qu’on commence à collaborer, tout le monde y gagne.</p>

<p>Souvent, l’être humain se contente de reproduire l’existant, ce qui est plus simple et limite les risques et efforts. Or, c’est lorsqu’il y a des contraintes fortes, qui nous sortent de notre zone de confort, que nous allons nous diriger vers des solutions originales et innovantes.</p><p>Mais comment trouver ces contraintes qui vont pousser à l’innovation, et comment être sûr que ce sont celles qui vont mener à une innovation génératrice d’une réelle valeur ? C’est une question que nous devons nous poser. Par exemple, nous avons vu beaucoup de fabricants de téléphones, dans leur course à l’innovation, ajouter des fonctionnalités qui étaient innovantes d’un point de vue technique, mais qui ne résolvaient pas de réels problèmes, ou offraient une solution inadéquate pour l’utilisateur. En d’autres mots, la réelle innovation se doit de résoudre un problème. Si l’on cherche à innover et ensuite à trouver le problème que cette innovation peut résoudre, l’innovation aura toutes les chances d’être inutile ou inadaptée.</p><p>Un exemple d’une telle fonctionnalité est le « 3D Touch » d’Apple. D’un point de vue technologique, c’était une innovation, mais du point de vue expérience utilisateur, cela ne résolvait pas de problème important et la solution proposée était inadaptée. Ce système permet de distinguer différents niveaux de pression sur la surface tactile de l’écran, mais cette fonction n’était pas essentielle et beaucoup d’utilisateurs ne savaient même pas qu’elle existait. Apple a fini par retirer cette fonctionnalité de ses <a href="https://www.theverge.com/circuitbreaker/2018/9/13/17854864/iphone%20-xs-max-3d-touch-waste-features-apple">modèles d’entrée de gamme</a> et devrait probablement la retirer de <a href="https://9to5mac.com/2019/07/09/digitimes-iphone-11-3d-touch/">tous les modèles</a> à sortir en 2019.</p><p>Le but de l’innovation est essentiellement de résoudre un problème. Le fait de vouloir le résoudre impose une contrainte, et cette contrainte génère de l’innovation. En d’autres termes : pour innover, identifiez en premier lieu le problème à résoudre. Ça peut être un problème majeur comme une petite chose agaçante du quotidien avec laquelle nous avons appris à vivre et que nous ne voyons plus.</p><p>L’innovation commencera lorsque nous mettrons des mots sur ce problème, le décrirons et le considérerons comme un bloquant pour lequel il faut trouver une solution. Ne plus pouvoir emprunter le chemin paraissant le plus simple, désormais bloqué par ce problème, impose une contrainte sur la solution à mettre en œuvre, et c’est cette contrainte qui va nous forcer à opter pour des cheminements que nous n’aurions pas envisagés en temps normal.</p><p>Cette partie d’identification et de verbalisation du problème, ainsi que la démarche pour trouver une solution sont les fondamentaux qui permettent l’innovation. Il est important qu’il y ait une compréhension de ce processus à tous les niveaux de responsabilité d’un projet afin de créer des conditions favorables à l’innovation. Il arrive parfois que la contrainte imposée à une équipe puisse paraître insurmontable, et il est important que les gestionnaires du projet soient prêts à gérer cette situation et à fournir les moyens, le support et les outils nécessaires à l’équipe pour avancer dans cette situation stressante, garder le moral et tendre vers l’excellence. Nous aborderons les différentes manières d’aider une équipe dans de telles conditions dans un futur article.</p><p>Un exemple d’innovation révolutionnaire, qui apparaît comme évidente aujourd’hui, mais qui ne l’était pas du tout à l’époque et qui a demandé un important travail, est l’interface utilisateur de l’iPhone. Lors de la création de l’iPhone, à l’époque des Pocket PC et autres téléphones pseudo intelligents, Steve Jobs ne voulait pas d’un stylet, car cela créait une mauvaise expérience utilisateur (et aussi parce qu’une personne de Microsoft qu’il détestait était en train de <a href="https://www.zdnet.com/article/steve-jobs-was-driven-to-create-iphone-by-obnoxious-microsoft-guy-with-stylus/">créer une tablette</a> avec un stylet). Dans un monde où tous les systèmes portables utilisaient des stylets pour pouvoir interagir sur un petit écran avec le plus d’informations possible, le fait de verbaliser le problème et de considérer qu’il fallait pouvoir utiliser uniquement ses doigts n’était pas du tout évident et posait une contrainte très forte sur les ingénieurs qui devaient trouver une solution efficace à ce problème.</p><p>La difficulté majeure ici était qu’il n’existait pas de solution connue afin de substituer, tout en offrant une meilleure expérience utilisateur, un système utilisant des doigts très imprécis à celui qui a recours à un stylet précis pour interagir avec de nombreuses données sur un petit écran. Les ingénieurs d’Apple ont dû imaginer un nouveau mode d’interaction homme-machine complet et créer un nouveau système d’exploitation autour de ce nouveau paradigme. Il fallait trouver comment faire défiler des données, comment se rendre compte qu’on arrive à la fin d’un défilement, comment présenter les données de façon efficace et facilement accessible tout en en affichant moins dans l’écran, comment les applications devraient se comporter, etc. Aujourd’hui, cela semble évident, mais à l’époque, quand le problème a été énoncé et la contrainte exposée, cela devait paraître irréalisable.</p><p>Cela nous montre que l’innovation, c’est aussi du courage, de la persévérance, beaucoup de travail et l’intuition qui nous dit qu’il existe une solution efficace et qu’on va la trouver.</p><p>Cependant, parfois, la contrainte qui résulte de la verbalisation d’un problème est relativement faible : une fois le problème verbalisé et la contrainte exposée clairement, la solution apparaît presque évidente. Combien de fois avez-vous découvert un petit logiciel qui résout un problème avec lequel vous vivez depuis des années sans réellement vous en rendre compte ou sans faire l’effort de le résoudre, et vous vous dites : « Mais bien sûr ! Comment n’y ai-je pas pensé avant, c’était pourtant si simple et évident ». Cela n’en reste pas moins une innovation.</p><p>Il ne faut pas cependant se laisser abuser par l’apparente simplicité d’une innovation, car comme nous l’avons vu avec l’interface utilisateur de l’iPhone, très souvent les meilleures innovations qui ont demandé beaucoup de travail apparaissent simples ou évidentes parce que la solution est brillante et efficace ; pourtant, la solution finale a demandé beaucoup d’efforts, d’essais et d’erreurs.</p><p>L’innovation est un sujet sans fin. Dans de prochains articles, nous aborderons certains sujets plus en profondeur, tel que :</p><ul> <li>Les moyens de générer des contraintes propices à l’innovation dans divers secteurs d’activité,</li> <li>La gestion du changement, des contraintes fortes dans une équipe,</li> <li>Comment détecter l’innovation qui apporte une vraie valeur à un produit,</li> <li>Etc.</li></ul>

<p>Le « console logging », c’est le pire. Certains peuvent contester mon opinion sur cet outil pratique, mais je pense que c’est une béquille qui est utilisée par beaucoup d’équipes malgré l’existence de meilleurs outils et méthodes de débogage.</p><p>Pour vous faire mieux comprendre ma pensée, je vais parler un peu de mon histoire. Mon premier langage de programmation professionnel a été Python. J’ai passé cinq ans et demi de ma carrière à développer des applications Python/Django, et l’une des choses que je préférais dans cet environnement était un outil appelé <a href="https://docs.python.org/3/library/pdb.html">PDB</a>, le Python Debugger.</p><p>Cet outil est à mon avis un rêve de développeur junior qui devient réalité. À tout moment, je pouvais stopper mon programme et inspecter son état du moment. Je pouvais observer le cycle de vie des variables. Je pouvais voir et suivre la pile des fonctions et des méthodes. En utilisant l’outil, non seulement j’ai pu résoudre les bogues et les problèmes plus rapidement, mais j’ai pu apprendre beaucoup de choses sur ce processus. J’avais l’impression d’avoir une vision à rayons X. Je me sentais comme un superhéros.</p><p>Avance rapide d’un certain nombre d’années, et j’ai commencé à travailler plus avec JavaScript. Mon bien-aimé PDB n’était plus là, mais j’ai rapidement appris à utiliser le débogueur et la console <a href="https://developers.google.com/web/tools/chrome-devtools/">DevTools</a> de Chrome. Ces outils ont répondu à tous mes besoins de débogage, proposant aussi un moyen facile et visuel d’ajouter des points d’arrêt à mon code. Je me suis une fois de plus senti comme un superhéros.</p><p>Dans ma fonction actuelle chez <a href="https://www.spiria.com/fr/">Spiria</a>, les applications sur lesquelles je travaille sont toutes en TypeScript. Nous utilisons Node et Express en back-end, avec une application React côté client. Du côté client, les choses vont toujours bien. Nous utilisons <a href="https://webpack.js.org">WebPack</a> pour transpiler le code TypeScript et générer les source maps, et nous sommes capables de déboguer dans Chrome comme nous l’avons toujours fait. En ce qui concerne le back-end, cependant, l’équipe dépendait exclusivement pour le débogage de l’enregistrement de la console. Notre processus de développement et de débogage consistait à faire des changements, à ajouter un tas de journaux de débogage, à exécuter le code, puis à analyser le journal de sortie pour essayer d’avoir une idée de ce qui se passait. C’était un processus lourd qui, à mon avis, produisait plus de bruit qu’il ne donnait des idées. Ma vision à rayons X avait disparu, et je ne me sentais plus du tout comme un superhéros.</p><p>De plus, contrairement à notre code front-end, le processus de compilation pour transpiler le code de back-end reposait sur une commande à lancer de façon manuelle. Le process de serveur ne surveillait pas non plus les changements et devait être redémarré manuellement si nous voulions que le dernier code transpilé soit reconnu. Après avoir passé quelques mois avec cet état de fait, je me sentais de plus en plus embourbé dans le processus, et j’aspirais à retrouver mes super-pouvoirs. Heureusement, je n’étais pas seul à me sentir ainsi, et notre équipe a été privilègiée de pouvoir prendre le temps d’améliorer ces processus.</p><p>Dans le cadre d’un projet qui impliquait un plus grand volume de travail en back-end, j’ai cherché à améliorer notre situation de débogage du mieux que j’ai pu. La première étape a été de récupérer des pouvoirs de débogage corrects. Heureusement, Node est livré avec un drapeau <code>--inspect</code>, qui ouvre un WebSocket sur un port particulier, exposant le processus Node pour le débogage. Chrome peut s’y connecter et ouvrir une instance de ses DevTools qui fonctionnent avec Node. Il y a même des extensions bien pratiques ; j’en utilise une appelée <a href="https://chrome.google.com/webstore/detail/nodejs-inspector-manager/bnmjajghllhhhgiaeipaibfmnjnponhd?hl=en">Node Inspect Manager</a> (NiM), pour ouvrir automatiquement DevTools quand un débogueur est exposé à un port prédéfini. Pouvoirs des rayons X revenus !</p><p>Cependant, j’étais toujours insatisfait du processus dans son ensemble. Chaque fois que j’apportais des modifications au code, je devais tuer mon process serveur, reconstruire le code du serveur et démarrer le process serveur. Il y avait là aussi une solution facile. Le transpileur TypeScript est livré avec un drapeau <code>--watch,</code> qui lui permet de retranspiler chaque fois qu’il détecte des changements de code. Pouvoirs métamorphes, ok !</p><p>Enfin, je voulais que mon process serveur redémarre chaque fois qu’il détectait des changements dans le code transpilé. Ce fut relativement facile aussi, avec un outil appelé <a href="https://nodemon.io">Nodemon</a>. C’est un wrapper léger autour de Node, qui redémarre le process lorsque des changements de code sont détectés. Il supporte les mêmes drapeaux que la commande Node ; notre processus de débogage était donc constamment actif. Vitesse de l’éclair, ok aussi !</p><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3708/wow.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3708/wow.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3708/wow.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3708/wow.png" style="width: 60%; border: none; " alt="Wow." title="Wow."></source></source></source></picture></p><p>Je me sentais à nouveau comme un superhéros. J’ai été capable d’écrire efficacement du code et de le déboguer à la volée. Nous n’avions plus à faire le travail de rebuild du code et de redémarrage manuel des process. Il y avait cependant un dernier élément qui m’embêtait encore, je devais lancer toutes ces commandes séparées pour voir les changements de code, et démarrer séparément Nodemon. Je me suis souvenu d’un outil que j’avais utilisé dans un projet précédent appelé <a href="https://www.npmjs.com/package/npm-run-all">npm-run-all</a>, qui est un excellent petit outil qui peut être utilisé pour exécuter un certain nombre de scripts distincts, en série ou en parallèle. Maintenant, nous entrons une commande, et npm lance <code>watch:server</code> ; le reste se fait comme par magie.</p><p>Des processus convenables pour le débogage sont cruciaux pour toute équipe. Tous les développeurs peuvent apprendre beaucoup en inspectant correctement leur code et leurs workflows, quel que soit leur niveau d’expérience. Il en résulte des applications plus performantes et sans bogues, pour satisfaire à la fois les développeurs, les différents intervenants et les clients.</p><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3708/yeah.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3708/yeah.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3708/yeah.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3708/yeah.webp" style="width: 60%; border: none; " alt="Wow." title="Wow."></source></source></source></picture></p>

<p>D’ordinaire, les clients d’entreprises de <a href="https://www.spiria.com/fr/services/">services logiciels</a> ne se rendent pas compte qu’ils ont besoin d’aide en matière de stratégie produit. Ils pensent que la relation se résume simplement à la fourniture d’un document de spécifications et que le fournisseur livrera un produit basé sur ce document. Mais cet état d’esprit est en train de changer parce qu’il y a des produits vraiment formidables qui ne décollent pas, ou décollent, mais n’arrivent pas à affronter les innovations et les changements du marché.</p><p>Les bonnes idées ne manquent pas, mais la plupart d’entre elles ont du mal à s’imposer sur le marché. La stratégie de produit aide à éclaircir et à comprendre ce problème. Elle vous aidera à déterminer si les caractéristiques du produit ratent la cible ou si vous mesurez bien l’expérience utilisateur. Elle doit également analyser si votre plan de commercialisation correspond à votre produit ou si une innovation récente peut perturber votre marché. Une saine gestion de produits doit faciliter l’évaluation de la situation du moment et l’élaboration de stratégies visant à accroître les revenus de l’entreprise.</p><p>Les stratégies pour obtenir au plus tôt dans le processus de développement des réactions du marché ciblé aident à améliorer la qualité du produit livré, et le délai de mise sur le marché est bien maîtrisé dans un espace de production au rythme rapide. Bien que des erreurs de produit se produisent, l’objectif d’une bonne gestion de produit est de valider au plus tôt les hypothèses et de développer des stratégies pour réévaluer en continu la façon dont un produit répond aux besoins du marché.</p><p>Aujourd’hui, les stratèges produits sont chargés de concevoir les stratégies de groupes de discussion adéquates – quand les réunir, que demander, de quelle manière, comment obtenir des retours opérationnels, quelles données recueillir, qu’en faire et comment les utiliser au mieux.</p><p>Dans de nombreux cas, les taux de satisfaction de la clientèle sont inférieurs aux standards de l’industrie. Mais pour le savoir, l’entreprise doit connaître ces standards. Les stratèges produits peuvent vous aider à mesurer la satisfaction de vos clients et à identifier et classer par ordre de priorité les fonctionnalités qui amélioreront votre produit. Ils vous mènent au stade où vous pouvez prendre des décisions éclairées en fonction des données disponibles.</p><p>Pour les entreprises qui servent une clientèle diversifiée, les stratèges produits peuvent aider de deux façons. Ils créent des profils types et des scénarios utilisateurs afin de mieux identifier les caractéristiques qui atténueront les conflits de l’utilisateur. Et ils travaillent sur les requis qui s’adressent à des utilisateurs très différents, tant en matière de contenus que de calendrier (les adeptes précoces comme ceux qui s’opposent au changement).</p><p>Les attentes des clients finaux en matière de rapidité de mise à niveau des fonctionnalités sont plus élevées que ce que de nombreuses entreprises peuvent fournir, et si celles-ci ne réagissent pas à temps, elles risquent de perdre des parts de marché. Les stratèges produits aident à naviguer dans les aspects commerciaux et techniques d’une problématique. Ils sont capables d’identifier les difficultés techniques rencontrées par l’entreprise et de recommander des solutions susceptibles d’augmenter le chiffre d’affaires et de réduire les coûts.</p><p>Les consultants en gestion de produits peuvent être d’excellents partenaires pour résoudre des problèmes. Vous n’avez qu’à trouver le bon et par la suite, faites-lui confiance. Comme le dit Warren Buffett, «<i> Le prix est ce que vous payez. La valeur est ce que vous recevez. »</i></p>

<p>En 2015, j’ai commencé comme développeur junior au sein d’une équipe de 10 personnes chez Spiria Toronto, anciennement DevBBQ. Ce fut un parcours fou, en montagnes russes, avec plein de gens étonnants et d’expériences mémorables qui furent l’occasion d’une grande croissance personnelle. Mais le plus important, c’est comment j’ai appris à devenir un meilleur développeur, à m’améliorer progressivement et à apporter une plus-value à l’entreprise avec mes compétences spécifiques. Cela dit, comme le dit le <a href="https://en.wikipedia.org/wiki/Ooh_La_La_(Faces_song)">grand classique</a> de Rod Stewart, « quand j’étais plus jeune, j’aurais aimé savoir ce que je sais maintenant ». Voici quelques leçons que j’ai apprises au cours des quatre dernières années.</p><h2>N’ayez pas peur de demander de l’aide</h2><p>Au début, j’hésitais à demander de l’aide à mes collègues. Je voulais avoir l’air compétent et faire croire que j’avais une bonne solution pour chaque problème particulier. Mais grâce à Kevin Zych, un de mes mentors, j’ai appris très tôt que cette notion était fondamentalement fausse. Au lieu de cela, la bonne approche consiste à demander conseil à un développeur senior, car elle tire parti de ses connaissances pour accélérer votre propre processus d’apprentissage. L’apport d’un développeur qui a déjà tout vu aide à résoudre les problèmes avec plus d’efficacité. Un autre énorme avantage de demander de l’aide est la possibilité d’examiner le problème d’un point de vue différent. C’est presque comme si une nouvelle connexion neuronale se formait dans votre cerveau, vous orientant vers une solution à laquelle vous n’auriez probablement jamais pensé par vous-même. J’ai eu la chance d’apprendre grâce à de grands mentors et de développer mes compétences plus rapidement que je ne l’aurais fait seul. Plus récemment, j’ai été de l’autre côté de la barrière, aidant d’autres développeurs à résoudre plus efficacement leurs problèmes. Cela m’a aidé à devenir un encore meilleur développeur, capable d’expliquer plus clairement les solutions.</p><h2>Pensez à l’avance à une solution</h2><p>Bien qu’il soit extrêmement bénéfique de demander de l’aide, ce n’est pas idéal si vous n’avez pas pensé au préalable à une solution potentielle. Faire ce travail de fond, c’est faire preuve de considération et de respect à l’égard du temps d’un autre développeur, en montrant que vous avez tenté de résoudre le problème par vous-même plutôt que de demander à être nourri à la cuillère pour trouver une solution. En fait, cela rend les autres développeurs plus disposés à vous aider. Avant de commencer quelque codage que ce soit, je développe une solution bien pensée à l’avance, en m’assurant qu’elle prend en compte les cas limites et les problèmes futurs. Ensuite, il s’agit simplement de valider ma solution et de mettre les doigts sur le clavier.</p><h2>Communication et collaboration</h2><p>Je venais d’un emploi où une seule personne prenait toutes les décisions, ce qui ne laissait pas beaucoup de place à la collaboration entre les membres de l’équipe. Le développement devrait être au contraire un travail d’équipe. La capacité de communiquer vos idées à un groupe de personnes ou même à un seul collègue est une compétence très importante à acquérir. Chacun, quel qu’il soit, a des informations précieuses à partager et doit être encouragé à s’exprimer, qu’il s’agisse d’explications d’estimations, de solutions, de demandes ou même des opinions. De plus, s’approprier vos solutions et se concentrer sur vos efforts au sein d’une équipe vous pousse vraiment à travailler à un haut niveau, surtout lorsque vous savez que vos collègues verront votre solution à un moment ou à un autre. Apprendre à communiquer, avec l’encouragement de mes pairs, m’a aidé à fournir de meilleures estimations et à arriver à de meilleures solutions en expliquant mes problèmes et mes réponses de façon concise.</p><p>Ce sont quelques-unes des leçons que j’ai apprises en tant que développeur junior, et je continue à les mettre à profit quotidiennement ! Elles ne sont peut-être pas applicables en permanence, mais j’aurais aimé les connaître quand j’ai fait mes débuts !</p><p>—</p><p>Besoin d’autres conseils ? Découvrez cet article écrit par Olivier Mageau-Pétrin de Spiria Gatineau : « <a href="https://www.spiria.com/fr/blogue/methodes-et-bonnes-pratiques/pour-en-finir-avec-le-junior/">Comment ne plus être un développeur “junior” ».</a></p>

<p>De nos jours, il devient de plus en plus difficile pour les entreprises de gérer leurs opérations sans applications, et la plupart de celles-ci sont exécutées sur des serveurs. Auparavant, chaque application avait besoin d’un serveur dédié pour fonctionner en toute sécurité et sans interruption. Pour s’assurer de ce bon fonctionnement, le service informatique devait se doter d’un serveur suffisamment puissant. Mais avant de mettre l’application en production, personne ne pouvait être vraiment sûr de ses besoins réels en puissance. Pour cette raison, le service informatique finissait la plupart du temps par acheter un serveur surpuissant qui ne serait utilisé qu’à 10 % ou moins de ses possibilités. C’était un grand gaspillage d’argent, d’espace et de temps.</p><p>Puis sont arrivées les machines virtuelles. Elles permettent d’exécuter en toute sécurité de nombreuses applications dans des environnements différents et sur un même serveur physique. Une nouvelle application n’est plus synonyme de nouvel achat matériel. Les serveurs qui n’utilisent qu’une petite partie de leur puissance peuvent finalement être utilisés au maximum de leur capacité ou presque. C’était un grand pas en avant pour l’univers informatique.</p><p>Mais rien n’est parfait et il y a toujours matière à parfaire. Les machines virtuelles consomment une bonne partie des ressources du serveur juste pour fonctionner. Elles doivent simuler un serveur physique avec tous ses composants : processeur central (CPU), mémoire vive, disque de stockage, carte réseau, etc. De plus, chaque machine virtuelle a besoin de son propre système d’exploitation, ce qui peut être une source de perte de performances, mais aussi de vulnérabilités logicielles.</p><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3366/vm-container.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3366/vm-container.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3366/vm-container.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3366/vm-container.png" style="width: 100%;" alt="VMs vs Containers." title="VMs vs Containers."></source></source></source></picture></p><p>Machine virtuelle (VM) et conteneur. Chaque conteneur fait appel au système d’exploitation du serveur hôte alors que chaque machine virtuelle héberge son propre système d’exploitation.</p><p>Par conséquent, il y a quelques années, la sphère Linux a commencé à travailler sur une nouvelle technologie qui est moins onéreuse et plus rapide : les conteneurs. Ils permettent d’isoler une application du monde extérieur sans avoir besoin d’un système d’exploitation dédié et d’un logiciel lourd pour simuler les composants physiques du serveur. Cela les rend plus rapides à exécuter et facilite la maintenance. Et ce n’est pas le seul avantage des conteneurs. Ils sont si rapides et petits que nous pouvons les utiliser pour diviser une application monolithique en plusieurs petits services qui communiquent entre eux. Chaque petit service peut ainsi fonctionner dans son propre conteneur, séparément des autres, afin qu’il puisse être entretenu ou réparé sans craindre de briser les autres parties.</p><p>Enfin, les conteneurs ont amélioré la plupart des services offerts par les machines virtuelles et sont plus adaptés à l’architecture logicielle moderne des microservices. Mais ils ne les remplacent cependant pas : bien souvent, nous les trouverons cohabitants côte à côte.</p><h2>Systèmes de conteneurisation</h2><ul> <li><a href="https://linuxcontainers.org/" target="_blank">Linux Containers</a> <ul> <li style="list-style-type: square;"><a href="https://linuxcontainers.org/lxc/introduction/" target="_blank">LXC</a></li> <li style="list-style-type: square;"><a href="https://linuxcontainers.org/lxd/introduction/" target="_blank">LXD</a></li> <li style="list-style-type: square;"><a href="https://linuxcontainers.org/lxcfs/introduction/" target="_blank">LXCFS</a></li> </ul> </li> <li><a href="https://www.docker.com/" target="_blank">Docker</a></li> <li><a href="https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/" target="_blank">Windows Server Containers</a></li></ul>

<p>Soyons clairs : dans ce contexte-ci, j’entends par « entreprise de services technologiques » une entreprise comme <a href="https://www.spiria.com/fr/">Spiria</a> – une entreprise qui offre des stratégies numériques, la conception et le développement d’applications modernes.</p><h2>Exposition à tous les secteurs d’activité</h2><p>En général, dans les entreprises de services, les développeurs sont rarement confinés à un seul secteur d’activité. Soins de santé, vente au détail, technologie financière, technologie marketing, et j’en passe : on touche à tout, et chaque secteur vient avec son propre lot d’expertises, de contraintes et de défis. Oui, il se peut que vous travailliez sur un seul projet ou pour un seul client pendant des mois, voire des années, mais normalement, les développeurs connaissent des changements dans leurs affectations. Ceux-ci ne sont pas si fréquents que le réajustement entre contextes différents devienne pénible, mais assez pour vous exposer à toute une palette de secteurs industriels, d’expertises sectorielles et de problématiques variées. Par ailleurs, en plus de votre propre projet, l’entreprise assume bien d’autres mandats en parallèle, ce qui vous donne autant d’occasions de tirer parti de l’expérience de vos collègues. Cette exposition vous permet de vous tenir au courant des besoins des entreprises et des différents secteurs, faisant de vous un meilleur développeur, capable de penser au-delà du code et de résoudre les problèmes plus efficacement.</p><h2>Défier l’obsolescence</h2><p>Comme développeur, l’exposition à la technologie est importante. Les grands développeurs (actuels ou en herbe) le recherchent par le biais de projets personnels (projet Open Source, produit/service en auto-entrepreneuriat…). La plupart des développeurs craignent toujours de se faire dépasser au fil de leur carrière. En effet, la technologie évolue par nature rapidement, et s’efforcer de la suivre, mois après mois, année après année, peut devenir essoufflant. Être dans une entreprise de services vous place dans un environnement où, chaque jour, des personnes aux vues similaires et aux compétences variées tentent de résoudre les problèmes de manière nouvelle, en utilisant des technologies différentes, avec des perspectives différentes et pour des secteurs d’activités différents. L’on n’est jamais à court d’aide, d’inspiration et de motivation pour garder les choses intéressantes.</p><h2>Gratification au-delà de la production de code</h2><p>Mon premier emploi, après cinq ans d’études en ingénierie logicielle, était dans un rôle de développement au sein d’une entreprise de services où j’ai rapidement acquis beaucoup d’expérience en relations interpersonnelles. Oui, il est important de pouvoir se concentrer sur son code, et penser en lignes d’instructions ; mais rencontrer les clients, les écouter parler de leurs besoins est ressourçant et stimulant. Voir leurs réactions à vos démonstrations, obtenir un retour direct sur votre performance comme développeur en observant leur réaction émotionnelle face à votre travail est une expérience gratifiante et riche en enseignements, qu’elle soit positive ou négative. Après tout, l’on développe pour des gens, et cette satisfaction personnelle peut dépasser celle de résoudre un problème d’ingénierie ou de fermer des tickets.</p><h2>Penser autrement</h2><p>Comme les entreprises de services travaillent toujours avec la contrainte d’un budget et contre la montre, les développeurs sont mis au défi de résoudre les problèmes d’une façon qui n’est peut-être pas immédiatement évidente. Par exemple, la solution qui coule de source ne cadre parfois pas avec le budget, et les développeurs doivent en trouver une autre qui respecte les besoins du projet et les exigences budgétaires. Les développeurs doivent chercher au-delà des bibliothèques et plug-ins disponibles, des morceaux de code de Stack Overflow. Aussi, trop souvent, les développeurs n’ont aucune idée de l’aspect commercial d’un projet, et les gestionnaires de projet se contentent d’annoncer des échéances sans expliquer ou justifier l’intensification du travail ou les dates de livraison serrées. Dans une entreprise de services, par contre, tout le monde est généralement conscient de l’état du budget et des indicateurs de performance de l’entreprise cliente. L’on ne peut qu’être motivé par cette transparence, et par le fait qu’on voit par soi-même la différence amenée par notre efficacité à résoudre les problèmes.</p><h2>Occasions de réseautage</h2><p>Si vous êtes du type entrepreneurial, vous allez aimer le fait qu’une entreprise de services vous permet de côtoyer de nombreux clients aux idées et aux besoins variés. Ce sont autant d’occasions, si vous le souhaitez, d’intégrer à votre réseau des personnes ayant noué un partenariat avec votre entreprise.</p><h2>À vous de voir</h2><p>Être développeur dans une entreprise de services, c’est travailler dans un environnement qui regorge d’occasions. Mais c’est aussi à vous de les saisir – elles ne seront pas distribuées d’office. Comme toujours, on en retire ce qu’on y cherche, en l’occurrence, tout ce que vous croyez être utile pour votre carrière. Le secteur des services est dynamique et exigeant ; ceux qui s’y investissent en retirent les dividendes de la satisfaction professionnelle et de la croissance personnelle.</p>

<p>Avec cet article, je souhaite illustrer à quel point la relation entre le Product Owner (PO) et l’équipe de développement est primordiale, et plus encore lorsque le PO est externe, du côté client. Les différences avec un PO interne sont nombreuses, mais parfois subtiles. Notez que je ne ferai aucune distinction entre les utilisateurs finaux internes et externes (développement d’outils internes par rapport à celui de produits logiciels) ; je pense que cela risquerait d’embrouiller les choses.</p><p>Pour tout dire, avant de cofonder Spiria en 2003, j’ai travaillé près d’une décennie sur des produits logiciels avec des PO internes, sauf qu’à l’époque, on les appelait simplement « chef de produit » ou « boss ». J’ai donc connu les deux côtés et peux offrir différentes perspectives.</p><h2>Jouer dans la même équipe</h2><p>Avec un PO interne, une appréciable différence est le sentiment généralement partagé que tout le monde joue dans la même équipe : c’est <i>nous</i>, l’équipe produit unie, contre <i>eux</i>, les hordes barbares qui frappent à la porte. Plus l’entreprise est petite, plus ce sentiment est important, particulièrement dans le cas de produits logiciels. Avec un PO externe, il y a souvent le danger que le <i>« nous contre eux »</i> se transforme en <i>nous</i> (le PO, le client) contre <i>eux</i> (l’équipe de développement, le prestataire de services).</p><p>De mon expérience de travail avec des clients externes, les projets les plus réussis ont toujours été réalisés avec une étroite collaboration entre le PO et l’équipe de développement, sans égard de la séparation client/fournisseur. En tant qu’équipe produit, <i>nous</i> avons fait des efforts concertés pour améliorer le produit final, y compris en reportant des fonctionnalités pour se concentrer sur la réduction de la dette technique, ou en faisant des coupes dans les coûts lorsque nécessaire.</p><p>De l’autre bord, lorsque le PO et l’équipe de développement ne travaillent pas complètement dans la même équipe, cela devient une partie de bras de fer permanente entre les deux. Avec le temps, l’équipe de développement s’impliquera moins dans le succès du projet et commencera à simplement obéir aux ordres du PO. Sur les projets à long terme, la qualité en souffrira, et des membres de l’équipe peuvent demander leur déplacement, ce qui est du gâchis pour le projet.</p><h2>Des avis qui comptent</h2><p>L’une des idées les plus fausses que j’ai entendues au sujet du travail avec un PO interne, c’est qu’on peut travailler comme on veut. Vous voulez passer de PHP à Node ? Pourquoi pas ! Ajouter un nouveau widget ? Bien sûr ! Vous avez vraiment besoin de rapports d’administrateurs avant de permettre à des usagers de se connecter ? Vous les avez.</p><p>Si les PO ne font que dire oui à tout, c’est qu’ils ne font pas un bon travail. Ils doivent orienter le projet dans la bonne direction, prioriser vraiment les idées et maintenir un contrôle serré du budget. Certains peuvent trouver qu’il est plus facile d’influencer un PO interne parce qu’ils sont du même camp, mais dans les entreprises bien gérées, les PO internes ont aussi des budgets et des délais à respecter.</p><p>D’un autre côté, les PO qui disent non à toutes les suggestions ne font sans doute pas non plus un très bon travail. Certes, vous avez parfois besoin de garder un contrôle très serré des fonctionnalités d’un MVP (<a href="https://www.spiria.com/fr/blogue/developpement-sur-mesure/le-pmv-la-strategie-gagnante-pour-etre-rapidement-sur-le-marche/">produit minimum viable</a>) en raison d’un salon professionnel à venir. Mais ce n’est pas toujours le cas. Et l’écoute des idées de tous les membres participe à la formation d’une équipe produit unie et fonctionnelle.</p><h2>Gestion de la dette technique</h2><p>J’admets qu’une version plus jeune de moi-même serait bien surprise à lire ce qui suit. Je considérais alors que toute dette technique était systématiquement mauvaise, que tout devait être conçu pour être à l’épreuve du futur, que tout devait être optimisé à la perfection et que tout devait être développé minutieusement comme il le faut.</p><p>Dans un monde idéal, peut-être. Nous avons sûrement passé beaucoup de temps à réusiner le code <i>(refactoring)</i> de fonctionnalités pratiquement pas utilisées ! Avec le temps, je me suis rendu compte qu’il n’y a parfois rien de mal à couper les coins ronds pour tester une fonctionnalité. Ce n’est pas aussi joli que ça pourrait l’être, mais c’est sans risque, ça ne vous donnera pas le cancer… Ensuite, laissez aller. Ajoutez une « story » de réusinage de code dans le « backlog » et passez à autre chose.</p><p>Il s’agit une fois de plus d’un exercice d’équilibre. De mon expérience, les PO externes ont tendance à être beaucoup moins indulgents à l’égard de la dette technique que les PO internes. « Déjà, pourquoi avez-vous laissé s’accumuler cette dette ? » Je ne saurais trop insister sur l’étroitesse de cette vision et comment cela peut mener à l’augmentation du temps de développement pour chacune des fonctionnalités demandées. Si vous n’avez qu’une seule chance pour coder quelque chose, vous voulez alors que ce soit d’emblée impeccable. Mais cela peut être du gaspillage si tout ce dont vous aviez besoin était de juste tester une fonctionnalité.</p><h2>Flexibilité du budget et des délais</h2><p>Avec un PO externe, il y a le sentiment que le budget est limité, alors qu’avec un PO et des développeurs relevant du même employeur, cela peut d’une façon ou d’une autre rendre le budget plus élastique. De même, avec un PO externe, des délais arbitraires deviennent par magie des dates gravées dans le marbre.</p><p>Il est cependant malheureux que cela se produise. Une possible cause est que les PO externes reçoivent généralement une copie de la facture de l’équipe de développement, et qu’ils sont ainsi incités à faire le suivi de projet en fonction de montants en dollars, alors que les PO internes se baseront avant tout sur le temps. Et parce que les délais arbitraires peuvent être modifiés, les budgets internes paraissent alors plus flexibles que les externes.</p><p>Cela dit, ça a pu être vrai avant, mais il y a de nos jours une pression accrue sur les PO internes pour qu’ils gèrent leurs projets avec la plus grande rigueur.</p><h2>Pour conclure</h2><p>Quel que soit le projet, un facteur clé pour s’assurer du succès est de faire travailler ensemble les membres de l’équipe produit (PO et équipe de développement). Chacun doit être conscient des délais, des contraintes et des objectifs du projet.</p><p>Lorsqu’il y a une bonne collaboration au sein d’une équipe produit, la dette technique demeure à un niveau raisonnable, les fonctionnalités sont classées par ordre de priorité, les délais sont respectés et le budget est maîtrisé. Et ceci reste vrai que le PO soit interne ou externe.</p>

<h2>Le but</h2><p>J’ai récemment voulu mettre un combo-box à l’intérieur des éléments d’une table à multiples colonnes. Bien que la façon standard de procéder soit simple, les résultats ne sont pas satisfaisants. Je voulais améliorer la solution normale pour rendre l’expérience plus agréable pour l’utilisateur. J’ai commencé par chercher des solutions toutes faites sur Internet. Bien que j’ai trouvé quelques idées dans le <a href="https://wiki.qt.io/Combo_Boxes_in_Item_Views">wiki de Qt</a> et sur <a href="https://stackoverflow.com/questions/18831242/qt-start-editing-of-cell-after-one-click">Stack Overflow</a>, il n’y avait pas de solution complète qui fonctionne à ma satisfaction.</p><p>C’est pourquoi je veux partager la solution que j’ai finalement trouvée récemment. Voilà ce que je voulais faire et pourquoi.</p><p>1. <strong>Je voulais mettre un combo-box directement dans un tableau multicolonnes.</strong></p><p style="margin-left: 1em;"><strong>Pourquoi </strong>: afin de pouvoir changer rapidement une valeur pour un élément de la liste. Ce n’est en fait pas difficile et il y a des exemples directement dans la documentation de Qt.</p><p>2. <strong>Je voulais que le combo-box soit toujours visible.</strong></p><p style="margin-left: 1em;"><strong>Pourquoi </strong>: pour que l’utilisateur sache que l’élément peut être édité directement. Par défaut, Qt garde le combo-box caché. L’utilisateur doit double-cliquer sur l’élément pour afficher la liste déroulante. Ce n’est pas facile à découvrir par l’utilisateur normal. Le résultat est que l’utilisateur ne sait même pas qu’un élément est modifiable !</p><p>3. <strong>Je voulais que le combo-box affiche le contenu de la liste déroulante dès le premier clic.</strong></p><p style="margin-left: 1em;"><strong>Pourquoi </strong>: normalement, dans Qt, le premier clic est utilisé pour sélectionner l’élément dans la liste. D’autre part, pour un combo-box normal, le premier clic affiche son contenu. Cette différence de comportement fait que le combo-box intégré dans la table fonctionne différemment d’un combo-box en dehors d’une table. Cela semble anormal pour l’utilisateur.</p><p>4. <strong>Je voulais que le clic sur le combo-box sélectionne la ligne du tableau.</strong></p><p style="margin-left: 1em;"><strong>Pourquoi </strong>: normalement, le clic sur le combo-box serait absorbé par le combo-box et la ligne ne serait pas sélectionnée, ce qui semblerait étrange pour l’utilisateur.</p><p>5. <strong>Je voulais que le combo-box termine l’édition de l’élément dès que l’utilisateur sélectionne un élément.</strong></p><p style="margin-left: 1em;"><strong>Pourquoi </strong>: normalement, Qt laisse l’élément de la liste en mode édition jusqu’à ce que l’utilisateur s’en éloigne avec le clavier ou en cliquant ailleurs. Encore une fois, ceci est incohérent comparé à la façon dont les combo-box fonctionnent en dehors d’un tableau.</p><h2>La solution</h2><p>Voici comment chaque objectif est atteint.</p><p>1. <strong>Placez le combo-box directement dans le widget de la table multicolonne.</strong></p><p style="margin-left: 1em;"><strong>Comment</strong> : en utilisant un <code>QStyledItemDelegate</code> qui crée un combo-box comme éditeur. C’est du code Qt standard et il est expliqué dans le <a href="https://wiki.qt.io/Combo_Boxes_in_Item_Views">wiki Qt</a>.</p><p>2. <strong>Rendre le combo-box toujours visible.</strong></p><p style="margin-left: 1em;"><strong>Comment </strong>: C’est aussi du code Qt standard : remplacer les fonctions <code>paint</code> et <code>sizeHint</code> du délégué. Le problème est que le code nécessaire n’est pas évident dans la documentation. En particulier, il n’est pas évident d’obtenir le style standard. Voir le code sur GitHub pour les détails.</p><p>3. <strong>Afficher le contenu de la liste déroulante au premier clic.</strong></p><p style="margin-left: 1em;"><strong>Comment </strong>: Cela nécessite trois astuces. La première est d’augmenter la fonction <code>mousePressEvent</code> de la table. Ceci permet d’entrer en mode édition avec le premier clic de souris. Dans la fonction <code>mousePressEvent</code>, nous lançons une minuterie qui appelle la fonction d’édition du widget de table avec l’index de l’élément sélectionné. (L’utilisation d’une minuterie est nécessaire pour que l’astuce de sélection de la ligne fonctionne plus tard.) Le second est de présélectionner l’élément courant dans le combo-box avec un appel à <code>setCurrentIndex</code> dans la fonction <code>setEditorData</code> du délégué. Le troisième est d’appeler la fonction <code>showPopup</code> du combo-box pour qu’il affiche son contenu immédiatement, dans la fonction <code>setEditorData</code>.</p><p>4. <strong>Sélectionnez la ligne du tableau en cliquant sur la liste déroulante.</strong></p><p style="margin-left: 1em;"><strong>Comment </strong>: nous devons à la fois sélectionner la ligne et lancer l’éditeur. C’est pourquoi nous retardons l’affichage de l’éditeur, sinon la sélection des lignes interférerait. Ainsi, dans la fonction <code>mousePressEvent</code>, nous appelons <code>setCurrentIndex</code> sur le modèle de sélection de table.</p><p>5. <strong>Terminez l’édition de l’élément dès que l’utilisateur sélectionne un élément.</strong></p><p style="margin-left: 1em;"><strong>Comment </strong>: Dans la fonction <code>createEditor</code> du délégué, quand nous créons le combo-box, nous nous connectons immédiatement à son signal <code>currentTextChanged</code>. La fonction connectée permet de valider les données et de terminer l’éditeur. Cela se fait en appelant la fonction <code>commitData</code> et la fonction <code>closeEditor</code> du délégué.</p><h2>Le code</h2><p>Le code C++ nécessaire pour avoir un combo-box toujours présent dans un widget de table est disponible dans ce <a href="https://github.com/pierrebai/QtComboBoxTableWidget">dépôt public sur GitHub</a>.</p><p>(L’exemple est fourni en tant que solution Visual Studio 2017.)</p>

<h2>Une période de démarrage trop furtive et sommaire</h2><p>Lorsqu’un nouveau projet démarre, tout paraît possible ! C’est la lune de miel, la nouveauté est enivrante, les possibilités sont infinies, l’excitation bat son comble. Quant à eux, les risques ne sont pas toujours perceptibles au premier regard et leur analyse exige temps et effort. C’est pourtant à ce moment critique qu’il faut leur accorder la plus grande importance puisque la gestion du risque est aussi la capacité à anticiper et à s’adapter à un écueil potentiel. Cela ne veut cependant pas dire qu’il faut craindre les rebondissements et obligatoirement tout prévoir, il faut un juste milieu.</p><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/istock-97926924.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/istock-97926924.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/istock-97926924.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3070/istock-97926924.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="decorative"></source></source></source></picture></p><p>Des rebondissements : oui, mais pas à n’importe quel prix ! © iStock.</p><p>Souvent appelée « Sprint 0 », « analyse », « conception », « découverte », peu importe le nom qu’on lui donne, cette étape est cruciale pour le projet. Elle permet de mettre la table, d’établir de bonnes bases, de prendre le temps de réfléchir et de préparer le projet à venir. Parmi les activités couramment incluses, nous trouvons l’élaboration des besoins du client, le raffinement du « backlog » de tâches à exécuter, la définition des critères de succès des « stories », la réalisation de maquettes fonctionnelles ou « wireframes », l’écriture du plan de test, la création d’environnements, la réalisation d’une démonstration de faisabilité ou encore d’études sur l’expérience utilisateur, etc.</p><p>De ce fait, comme dans toute nouvelle initiative, il y a souvent cet empressement naturel qui nous porte à vouloir rapidement entrer dans le vif du sujet. De plus, cette hâte peut être accentuée par des contraintes telles qu’un échéancier serré ou un budget limité. C’est ainsi que les premières étapes pourtant cruciales d’un projet se retrouvent très souvent escamotées et dépriorisées. Un manque de vision s’en suit alors et les risques de réécriture deviennent alors proéminents.</p><p>C’est un peu comme construire une maison en n’ayant fait ni plan ni inventaire des matériaux nécessaires. Il se pourrait que vous deviez par la suite déplacer un mur ou encore retourner souvent à la quincaillerie ou chez d’autres fournisseurs pour vous procurer le matériel nécessaire.</p><h3>Solution</h3><p style="background-color: #dadac5; padding: 9px 12px;">Il nous a été démontré maintes et maintes fois au cours de notre pratique, qu’avant même le début de l’exécution du projet, un effort de 15 à 20 % du montant total du projet devrait être accordé aux étapes préparatoires. Cela peut paraître un gros investissement pour peu en retour, mais détrompez-vous ! Cette étape vous fera suffisamment gagner sur l’efficacité de réalisation et limitera les efforts de réécriture à un point tel que vous serez convaincu de sa valeur. Faites-en l’essai par vous-même et vous verrez !</p><h2 style="padding-top: 3em;">Temps de réusinage de code non prévu dans le plan de projet initial</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/graphique-melissa.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/graphique-melissa.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/graphique-melissa.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3070/graphique-melissa.png" style="width: 100%; border-style:solid; border-width:1px;" alt="decorative"></source></source></source></picture></p><p>D'après <a href="https://twitter.com/johncutlefish/status/961840154385072128">John Cutler</a>.</p><p>Quel que soit l’échéancier d’un projet, un imprévu technologique majeur nous fait l’effet d’un ciel qui nous tombe sur la tête à 10 110 011 km/h !</p><p>Le réusinage (« refactoring ») fait partie des processus nécessaires à chaque itération/période de développement. Il consiste à retravailler le code source de façon à le normaliser et améliorer sa structure interne, sans modification du comportement externe du code. Il exclut donc tout ajout de fonctionnalités ou correction de bogues. Il rend le logiciel plus aisé à comprendre et à maintenir, il aide à repérer les bogues et accélère la programmation.</p><p>C’est un peu comme faire du ménage dans ses placards et bien organiser le contenu de ses tiroirs afin d’accueillir du nouveau contenu et de faire en sorte qu’il sera simple d’y accéder par la suite.</p><h3>Solutions</h3><p style="background-color: #dadac5; padding: 9px 12px;">Lorsqu’un projet est construit sur des bases existantes, soit avec l’utilisation du code qui ne vous appartient pas, soit avec du code hérité d’une technologie qui n’est plus prise en charge, il faudra prévoir du temps pour le réusinage de code.</p><p style="background-color: #dadac5; padding: 9px 12px;">Toutefois, même si votre projet débute à partir d’une planche à dessin vierge et que vous en êtes l’instigateur, on ne s’en sort pas ! Il faudra tout de même prévoir du réusinage assez rapidement dans le projet et le besoin sera plus accru avec l’évolution du projet et l’ajout de nouvelles fonctionnalités. Il faudra donc planifier dans les sprints de mi-projet et les avant-derniers sprints une part plus importante de réusinage. Notre pratique nous a démontré que 10 % de réusinage était normalement suffisant pour que le logiciel demeure facile à comprendre, à déboguer et à entretenir, en plus d’accélérer la programmation par la suite.</p><h2 style="padding-top: 3em;">Plusieurs ajouts et changements acceptés en cours de route sans signalement formel</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/dsc_0314-1.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/dsc_0314-1.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3070/dsc_0314-1.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3070/dsc_0314-1.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="decorative"></source></source></source></picture></p><p>© Spiria.</p><p>Bien que l’on pourrait croire qu’a priori un client sera nécessairement plus heureux si l’on fait plus que la demande originale et qu’on accepte tous les changements de dernière minute, il le sera moins s’il réalise que son projet est alors menacé par ces ajouts ou encore que ses contraintes budgétaires ne puissent plus être respectées. Il importe donc d’être transparent avec les clients, de documenter les changements et d’évaluer chaque demande pour ensuite prévenir le client des impacts financiers potentiels ou encore des conséquences que ceux-ci pourraient avoir sur l’échéancier du projet. Même lorsque l’impact vous paraît minime, il est important de le documenter et de le suivre, car un amoncellement de petits changements négligeables peut avoir un impact considérable sur votre projet si vous ne les suivez pas attentivement. Un océan est formé de nombreuses petites gouttes d’eau lui aussi !</p><h3>Solution</h3><p style="background-color: #dadac5; padding: 9px 12px;">Tenir un registre des changements, comme on tient un registre des risques, est une solution essentielle. On le met idéalement en ligne et on invite le client à le consulter chaque fois que l’on y ajoute du contenu. On priorise ensuite les demandes de façon à ne pas menacer l’objectif initial des sprints et du projet avec des éléments intéressants à avoir, mais non prioritaires. Pour certains gros projets, les demandes de changements sont si nombreuses qu’une rencontre hebdomadaire y est consacrée, possiblement jumelée avec celle du suivi de bogues et/ou des risques.</p><p>Pour conclure, c’est grâce à une solide expérience découlant d’un portefeuille de projets variés, une communication efficiente, une grande attention portée au transfert de connaissances, autant en développement qu’en gestion de projets, que l’on s’assure que les meilleures pratiques soient utilisées lors de croisades en terres numériques.</p><p>Je recommande fortement de tenir une liste de leçons apprises et l’historique des problèmes/solutions, puis d’assurer le partage des apprentissages à l’ensemble des communautés de pratique. Ceci permettra d’assurer une amélioration continue au sein des pratiques et de transformer le savoir individuel et collectif en apprentissage organisationnel. Dans le contexte concurrentiel que nous sommes aujourd’hui, une telle démarche pragmatique d’évolution est au cœur de ce que présente l’entreprise apprenante.</p>

<h2>Concilier les exigences du travail et de la famille</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/julien-d.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/julien-d.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/julien-d.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3019/julien-d.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Julien, analyste-programmeur et Scrum Master." title="Julien, analyste-programmeur et Scrum Master."></source></source></source></picture></p><h3>Julien, développeur sénior</h3><p>Il y a toujours un moment où l’on doit concilier travail et vie personnelle. Que ce soit la livraison d’une nouvelle laveuse un mardi entre 9 et 17 heures, la visite d’un plombier pour un dégât d’eau dans la salle de bain, un rendez-vous chez le dentiste, la pose de pneus d’hiver ou encore cette rare fois où vous tombez malade. Il est toujours pratique de pouvoir ajuster l’horaire de sa journée, de manquer quelques heures pour les récupérer un autre jour ou de pouvoir travailler à l’occasion de la maison. Mais lorsque vous avez des enfants, c’est là que la réalité de la conciliation travail-famille vous devient essentielle. Il y a le transport des enfants au CPE et à la garderie qui vient gruger de précieuses minutes de votre journée. Les multiples rendez-vous de suivi chez le médecin et les vaccins au CLSC peuvent toujours se planifier, mais pas mal moins les appels de la garderie en fin de matinée qui vous demande de venir chercher votre enfant qui a (encore !) la gastro (et qui vous la donnera généreusement dans les prochains jours).</p><p>Si vous êtes moins chanceux, un de vos enfants peut avoir un problème mineur de santé qui demande des suivis annuels avec un chirurgien cranio-maxillo-facial, un ORL, un ophtalmologiste et un audiologiste. Ou encore, il pourrait avoir un retard de langage et devoir rencontrer un orthophoniste toutes les deux semaines. Ou bien un autre enfant pourrait avoir un problème cardiaque, être opéré à cœur ouvert très tôt dans sa vie et devoir faire des suivis constants chez le cardiologue. Et si vous êtes moi, vous vivez tout cela à la fois.</p><p>C’est là que vous comprenez la valeur d’un employeur qui vous offre cette conciliation travail-famille. Spiria demande à chacun d’être flexible. Mais Spiria sait aussi être flexible en offrant cette conciliation. Plus d’une fois, j’ai pu profiter de cette flexibilité pour pouvoir assurer mes responsabilités familiales. J’ai pu modifier mon horaire ou bien travailler de la maison. Mes coéquipiers ont pu m’aider à accomplir à temps mes tâches. Pour s’assurer qu’un projet ne prendrait pas de retard, j’ai même pu être remplacé lors d’une longue absence. Je n’ai jamais senti que c’était un problème que de pouvoir être accommodé pour prendre soin de ma famille. Il me suffit de prévenir dès que je suis au courant d’un possible dérangement et tout le monde s’adapte. Spiria écoute, fait preuve de compréhension et propose des solutions pour que vous puissiez passer au travers de votre semaine ou de votre année sans y laisser votre peau. Alors, après cette année particulièrement difficile et éprouvante pour moi, je ne peux que dire : merci !</p><h2>Aucun junior ne pourrait être aussi bien qu’ici</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/antoine-f.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/antoine-f.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/antoine-f.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3019/antoine-f.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Antoine, programmeur." title="Antoine, programmeur."></source></source></source></picture></p><h3>Antoine, développeur</h3><p>Je n’ai jamais pensé à faire autre chose que travailler avec des ordinateurs. Je ne savais pas exactement ce que je ferais avec eux, mais j’ai toujours su, dès mon plus jeune âge, qu’ils seraient mes meilleurs amis. La technologie est ma première, deuxième, troisième et quatrième passion, c’est juste une partie de qui je suis, de mes amitiés et de ma vie en général.</p><p>Travail, ça me semble un mot étrange, je n’ai jamais vraiment eu l’impression que la programmation était un travail ! C’est juste ce que j’aime faire, et je suis payé pour le faire, qu’est-ce qui pourrait être encore mieux ? Eh bien, il y a une importante différence ! Coder, c’est quelque chose, travailler dans une entreprise en tant que codeur, c’est différent !</p><p>Les programmeurs sont trop souvent perçus comme des blocs monolithiques pouvant être déplacés de la zone A à la zone B, sans même s’interroger sur ce que leur lieu de travail leur apporte. Mais voici une nouvelle pour vous : nous ne sommes pas des robots, et, oui, nous nous soucions du bureau et de l’ambiance générale de notre lieu de travail ! Quelles sont les stacks avec lesquelles vous travaillez ? À quoi ressemblent les relations avec le patron ? D’autres collègues aiment-ils échanger et partager leurs connaissances ? Est-ce que les développeurs ne sont que des numéros ?</p><p>Du point de vue d’un junior, quand il s’agit de trouver un emploi dans l’industrie du logiciel, c’est vraiment comme une approche Tindr, glisser-déplacer-droite, glisser-déplacer-gauche… Messages sur LinkedIn, offres par courriel, etc. Pour ce qui est de la communication d’entreprise, les RH sont très bonnes pour attirer les jeunes talents avec une image qui dans les faits ne reflète pas la routine quotidienne. L’entreprise essaie de briller comme Google pour attirer l’attention, mais quand il s’agit du travail quotidien de base, la réalité prend le pas sur la projection d’images en couleurs. Ils se vantent de leur stack innovante, mais une fois que vous y êtes, ce n’est plus que du PHP et du code WordPress pitoyable.</p><p>En tant qu’entreprise, si vous mentez sur ce que vous êtes vraiment, vos nouveaux employés commenceront à se rendre compte qu’ils ont été trompés et iront à la recherche de nouveaux défis. Jamais vous ne pouvez dire à un développeur créatif : « Nous ne faisons que du PHP ici, donc adaptez-vous et rentrez dans le moule ». Nous sommes des esprits riches, nous avons besoin de défis et de stimulations, ou bien nous nous ennuyons et passons à autre chose.</p><p>Voilà un fait : si votre entreprise comprend vraiment l’industrie du logiciel, les développeurs seront dans une lune de miel sans fin avec leur travail ! Se lever le matin pour se rendre au bureau sera la meilleure chose qui puisse leur arriver dans la journée. Ma grand-mère me dit toujours que j’ai de la chance d’être heureux au travail, et, oui, je le suis vraiment.</p><p>D’après les sondages, peu de travailleurs aiment leur travail... Mais je ne suis pas l’un d’entre eux. Chaque matin, je me sens heureux de sortir du lit et d’aller travailler. C’est un objectif que mes parents ont passé toute leur vie à atteindre. Être au début de la vingtaine et être si heureux d’aller travailler est une chance, c’est difficile à expliquer, on ne peut le comprendre que si on le vit.</p><p>Spiria, vous fusionnez la créativité, la passion, l’honnêteté, l’intégrité et l’inclusivité dans un tout. Ce n’est pas qu’une image. Vous êtes vraiment ce que vous prêchez et je ne pourrais pas imaginer être plus heureux hors de vos murs. Une entreprise animée par l’amour d’écrire des logiciels et de repousser les limites ! Un c***** de grand merci ! Jamais un junior ne peut être plus heureux que là où je suis en ce moment.</p><p>De la tête et du cœur, merci. Avec amour.</p><h2>Ma voix est entendue et considérée</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/jose-m.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/jose-m.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/jose-m.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3019/jose-m.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Jose, analyste en assurance qualité." title="Jose, analyste en assurance qualité."></source></source></source></picture></p><h3>Jose, analyste en assurance qualité</h3><p>En 2017, lors de mon entretien d’embauche avec Jean Godard et Guy Verville, il y avait l’esprit de l’entreprise qui passait à travers eux. J’avais l’impression d’équipes communautaires extraordinaires, le sentiment que le respect et la véritable sincérité étaient dans l’air. Tout était « Oui ».</p><p>J’ai posé de questions. « Puis-je développer mes compétences professionnelles dans cette entreprise ? » « Oui, et l’entreprise t’aidera. » « Mais mon français n’est pas si bon que ça, pouvez-vous m’aider avec ça aussi ? » « Oui, l’entreprise t’aidera. » « Si je démontre que je peux faire plus pour l’entreprise, me donnerez-vous l’occasion d’en faire plus ? » « Oui, l’entreprise t’aidera et t’orientera dans la bonne direction. » Tout ces « Oui » et surtout « l’entreprise t’aidera » a été pour moi un accueil des plus étonnants et cela signifie beaucoup. Et je trouve plus dans Spiria, bien plus. Des amis, des sourires… Je peux dire que ma famille est ici aussi.</p><p>L’entreprise possède quelque chose de rare à trouver, le sentiment et le fait que votre voix peut être entendue et être considérée. C’est une énorme motivation à être plus impliqué dans toutes les tâches, tout en sachant que vous n’êtes jamais seul et que l’aide est toujours là, il suffit de demander. Après plus d’un an et demi chez Spiria, je peux dire que le « Oui, et l’entreprise t’aidera » est plus fort que jamais. Il n’y a pas de limite à ce que je peux faire ou à ce que je veux être au sein de cette équipe extraordinaire. Je voudrais aussi aider les nouveaux arrivés ou les plus anciens à voir ce que je vois depuis le premier jour.</p><p>J’aimerais remercier sincèrement Jean Godard, Guy Verville, l’équipe d’AQ et les équipes de projets que j’ai côtoyées, pour toute cette aide. Comme je l’ai dit un jour : « Faire partie de l’équipe Spiria, c’est penser dans différentes langues, sourire de différentes manières, tout en se sentant bien avec des gens sympathiques autour, avec des amis. »</p><h2>Le plaisir et le bien-être au travail</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sandra-f.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sandra-f.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sandra-f.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3019/sandra-f.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Sandra, chargée de projets." title="Sandra, chargée de projets."></source></source></source></picture></p><h3>Sandra, chargée de projets</h3><p>Quand on y pense, je passe plus de temps au travail qu’avec ma famille. Pour moi, il était essentiel de trouver une entreprise dont les valeurs correspondent aux miennes et qui m’offre la possibilité d’évoluer professionnellement.</p><p>Pourquoi Spiria ? La diversité des projets et l’offre de services. Une chose est certaine, chez Spiria je ne manquerai jamais de défis ! Chaque projet est unique, tant au niveau de l’équipe que des technologies utilisées. Chaque solution numérique est développée vraiment sur mesure pour le client.</p><p>Dans le cadre des fonctions de mon travail, j’aime avoir une marge de manœuvre. J’aime être impliquée dans les décisions et ajouter ma couleur. Spiria accorde cette latitude aux employés. Également, l’entreprise offre toute une panoplie d’outils pour développer ses compétences, comme des cours de langue, un accès à des formations externes, des ateliers sur le développement personnel, des « foires du savoir », etc. Il y a de tout, et pour tous les goûts.</p><p>Aussi chez Spiria, on met en avant le « fun ». Le plaisir et le bien-être au travail sont au rendez-vous. Il y a une variété d’activités sociales, des « 4 à fun » en passant par le Noël des enfants à M. Crème Glacée, des paniers de fruits frais, de superbes locaux et des gens vraiment super ! On prend soin de ton corps comme de ton esprit...</p><p>Et on sait reconnaître mon travail. Que ce soit via le journal interne, l’écran d’annonces ou mon gestionnaire, on prend le temps de partager les bons coups par différents moyens. Et les moins bons, on n’a pas peur d’en parler pour éviter de les répéter à l’avenir.</p><p>C’est lorsque tu te lèves le matin et que tu es motivée à relever les défis que tu sais que le bonheur, eh bien, il est là...</p><h2>Un management disponible et à l’écoute</h2><p><picture><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sergii-b-2.400x0.webp" media="(max-width: 599px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sergii-b-2.760x0.webp" media="(max-width: 999px)"><source type="image/webp" srcset="https://mirror.spiria.com/site/assets/files/3019/sergii-b-2.1039x0.webp" media="(min-width: 1000px)"><img src="https://mirror.spiria.com/site/assets/files/3019/sergii-b-2.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Sergii, analyste en assurance qualité." title="Sergii, analyste en assurance qualité."></source></source></source></picture></p><h3>Sergii, analyste en assurance qualité</h3><p>Spiria est la première entreprise où j’ai commencé à travailler après mon immigration au Canada. J’ai eu la chance de trouver cet emploi quelques semaines après mon arrivée. Avant, j’étais dans une entreprise qui développait son propre produit, ce qui signifiait travailler toujours sur le même projet. Spiria m’offre une expérience totalement différente : un environnement Agile, des projets intéressants pour des clients de différents secteurs d’activité et des possibilités de développement professionnel.</p><p>C’est une grande expérience que de travailler ici, dans cette période fascinante où l’entreprise est en pleine croissance, a une mission à mener à bien et une vision d’avenir. Construire la bonne structure, établir une matrice où chacun peut sentir qu’il contribue à quelque chose de grand et d’important.</p><p>L’une des plus grandes différences entre Spiria et mon expérience précédente, c’est l’approche du management. Lorsqu’une entreprise se développe et que les équipes s’agrandissent, vous ne voulez pas vous sentir perdu et oublié. Ce n’est pas le cas ici. Les gestionnaires sont toujours disponibles et heureux d’être à l’écoute. Ils sont ouverts à toute suggestion qui pourrait améliorer le processus de travail ou le moral de l’équipe. Il y a des rencontres régulières où vous pouvez vous exprimer, discuter de perfectionnement professionnel et des prochaines étapes, demander ou donner de la rétroaction, ou simplement parler de la façon dont vous avez passé votre fin de semaine et du plaisir que vous avez eu. Elles vous donnent l’impression d’être pris en charge et consolident les relations professionnelles.</p><p>J’apprécie également la confiance et la flexibilité : la possibilité de travailler à domicile, de venir au bureau avant ou après les heures de pointe, de rester à la maison en cas de circonstances imprévues. Toutes ces choses construisent une relation de confiance et d’honnêteté qui motive à être productif et à contribuer autant que possible.</p><p>Et bien sûr, je dois mentionner cette grande excitation lorsqu’un projet s’achève, et que vous avez le sentiment que la mission a été accomplie avec succès. Puis vient un autre sentiment : anticiper que le prochain projet pourrait être encore plus intéressant et stimulant, ce qui est génial !</p><p>Un lieu de travail agréable, du matériel performant, des avantages pour les employés, différentes activités sociales, la possibilité de passer du temps avec des collègues en dehors de l’environnement de travail et de nombreux autres petits détails créent l’impression générale que je suis au bon endroit. Et je ne parle pas du délicieux café et du réfrigérateur rempli de lait, de jus et de fruits, parce que c’est quelque chose qu’on doit avoir au bureau de nos jours.</p><p>Pour résumer tout cela, je peux juste dire que je suis un gars ukrainien qui se réjouit de sa vie chez Spiria, qui me donne tout ce dont j’ai besoin pour continuer mon développement professionnel et avoir du plaisir pendant cette période passionnante de ma vie.</p>

<p>Aujourd’hui, tous les sites Web publiés après 2013 en Ontario sont tenus d’être conformes au niveau A. Voici les exigences que j’ai trouvées plus souvent que d’autres négligées :</p><h2>1. Balisage sémantique (niveau A – 1.3.2)</h2><p>Le balisage sémantique est un terme sophistiqué pour une utilisation du HTML pleine de bon sens. Les en-têtes de pages et de sections doivent être entourés de balises d’en-tête (H1, H2, etc.). Un titre H1 ne doit être utilisé qu’une seule fois pour le titre de la page, mais les balises H2, H3, etc. peuvent être utilisées autant de fois que nécessaire.</p><p>Il est important d’utiliser une structure de titres et de paragraphes pour afficher le contenu parce que les lecteurs d’écran utilisent souvent ces titres structurés pour indiquer le début et la fin du contenu. Si une page n’a pas de titres, les utilisateurs ne verront ou n’entendront qu’un énorme mur de texte sans pause.</p><h3>Les « pauses thématiques »</h3><p>Lors du formatage du contenu en HTML, les changements de contexte peuvent être marqués par des « pauses thématiques », représentées par la balise HR. Ceci indique au lecteur d’écran qu’il devrait y avoir une pause lors de la lecture du texte et signifie également à l’utilisateur un changement de sujet, au lieu d’un texte en continu.</p><h3>Changements de langue</h3><p>Imaginez une voix synthétique anglaise lisant des mots français ou espagnols comme s’il s’agissait de mots anglais. L’indication des changements de langue garantit que le contenu est lu à haute voix avec précision par la technologie d’assistance, comme le lecteur d’écran.</p><p>Par exemple :</p><pre><code>&lt;span lang="EN"&gt;I love chocolate.&lt;/span&gt; </code></pre><h2>2. Formulaires et étiquettes de champs (niveau A – 3.3.2)</h2><p>Les formulaires doivent toujours être logiques et intuitifs, leurs champs correctement étiquetés et il est nécessaire de fournir des instructions claires. Les champs obligatoires doivent être indiqués et les étiquettes de champs doivent être présentes dans le code, même si elles ne sont pas visibles dans le design visuel.</p><pre><code>&lt;label for="courriel" class=”hidden”&gt;Adresse de courriel&lt;/label&gt; &lt;input class="form-control" id="courriel" name="courriel" type="text" placeholder="Adresse de courriel" /&gt; </code></pre><p>Une étiquette associée à une entrée sera prononcée par les lecteurs d’écran lorsque le champ sera sélectionné. Cela permet également à l’utilisateur de cliquer sur l’étiquette pour activer le contrôle.</p><h2>3. Liens : texte, couleur et focus (niveau A – 2.4.4)</h2><p>Les personnes avec un lecteur d’écran utilisent souvent une liste déroulante de tous les liens contenus dans une page. Il est important d’avoir des liens qui donnent le contexte approprié. Par exemple, une liste de liens « cliquez ici », « cliquez ici », etc. est désastreuse pour l’accessibilité. À la place, il est beaucoup plus clair pour les utilisateurs de fournir une contextualisation dans le texte du lien, par exemple : « Téléchargez le rapport annuel ».</p><h3>Survol et focus (niveau A – 1.4.1)</h3><p>L’état de survol d’un lien ne peut pas s’appuyer uniquement sur la couleur pour transmettre un sens. Il se peut qu’une personne daltonienne n’ait pas accès à l’information sur les couleurs, et les utilisateurs de lecteurs d’écran n’y auront pas accès non plus. À la place, ajoutez un soulignement en plus de la couleur qui aidera les utilisateurs à comprendre qu’il s’agit d’un lien.</p><h2>4. Inclure des descriptions d’images (niveau A – 1.1.1)</h2><p>L’ajout de texte alternatif aux images est souvent une réflexion après coup et aboutit à des descriptions d’images comme « image » et « nom de fichier.jpg », ce qui signifie que les utilisateurs passent à côté d’un élément clé de l’accessibilité.</p><p>Il est important d’avoir un texte descriptif pour les utilisateurs qui ne peuvent pas voir ces images. Une technique pour déterminer le texte alternatif d’une image serait de regrouper les images dans les trois catégories suivantes : simples, complexes ou décoratives.</p><h3>Simples</h3><p>Ces images sont des photographies, des icônes ou des logos, et le texte descriptif doit être succinct.</p><pre><code>&lt;img src="fleurs.jpg" alt="Fleurs dans un jardin." /&gt; </code></pre><h3>Complexes</h3><p>Ces images sont des diagrammes ou des graphiques et le texte descriptif sera plus détaillé.</p><pre><code>&lt;img src="diagram.jpg" alt="Figure 1. Taux d'utilisation des lecteurs d’écran au Canada" /&gt; </code></pre><h3>Décoratives</h3><p>Ces images sont purement décoratives, l’attribut <i>alt</i> est vide et un attribut de rôle indique <i>presentation</i>. Cela signifiera au lecteur d’écran d’ignorer l’image.</p><pre><code>&lt;img src="espacement.png" alt="" role="presentation" /&gt; </code></pre><h2>5. Navigation au clavier (niveau A – 2.1.1)</h2><p>L’une des caractéristiques les plus importantes de l’accessibilité est la possibilité de naviguer sur un site Web avec uniquement le clavier.</p><p>Les utilisateurs doivent pouvoir naviguer dans le contenu et les éléments de manière séquentielle et cohérente (niveau A – 2.4.3). En ajoutant un attribut <i>tabindex</i> de valeur 0 à un élément, cela |'insère dans l’ordre de tabulation en fonction de son emplacement dans le code source. Ceci permet également à n’importe quel élément d’avoir le focus.</p><p>L’état de focus doit être présent et cohérent pour tous les éléments de navigation (niveau AA – 2.4.7). C’est une bonne pratique lors de la création de composants personnalisés d’utiliser des éléments HTML « focalisables ». Cela vous permet de profiter de la fonctionnalité par défaut, autrement le focus au clavier et le support d’interactions doivent être fournis.</p><p>Enfin, l’ajout d’un lien de saut direct vers le contenu principal permet au lecteur d’écran de passer le bloc des éléments de navigation, évitant ainsi d’avoir à passer en revue chaque lien sur chaque page. (Niveau A 2.4.1.)</p><h3>Ressources sur l’accessibilité (en anglais)</h3><ul lang="en" xml:lang="en"> <li><a href="http://contrast-finder.tanaguru.com">Contrast Finder</a>.</li> <li><a href="https://www.powermapper.com/products/sortsite/">SortSite</a>, a one-click web site testing tool.</li> <li><a href="https://webaim.org">WebAIM</a>, training, certification and assistance</li></ul><h3>Sources</h3><ul lang="en" xml:lang="en"> <li>Ontario.ca: “<a href="https://www.ontario.ca/page/how-make-websites-accessible">How to make websites accessible</a>.”</li> <li><a href="https://www.w3.org/TR/WCAG21/">Web Content Accessibility Guidelines (WCAG) 2.1</a>.</li> <li>Mozilla: “<a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility">Handling common accessibility problems</a>.”</li> <li>University of Washington: “<a href="https://www.washington.edu/accessibility/checklist/images/">Making Images Accessible</a>.”</li> <li>WebAIM: “<a href="https://webaim.org/techniques/keyboard/">Keyboard Accessibility</a>.”</li></ul>