Introducing a new tech stack to government

Caley Brock

May 08, 2019

La version française est en dessous de l’anglais 👇

From left: Code for Canada fellows Siobhan, Joey and Caley have been working with the Public Service Commission of Canada to modernize their job assessment tools.
From left: Code for Canada fellows Siobhan, Joey and Caley have been working with the Public Service Commission of Canada to modernize their job assessment tools.

As Code for Canada fellows, we have two parallel missions: deliver a great product or service and openly share our tools and processes with our government colleagues. These goals are often inseparable; delivering products that are intuitive and responsive to the needs of your users requires reimagining how you build those products.

To demonstrate how these two concepts — what you build and how you build it — are connected, I want to share the journey of how our fellowship team helped introduce a new technology stack to the Public Service Commission of Canada (PSC). If you’re not familiar with the term, a tech stack is the set of software languages (things like Javascript, Python or Ruby), frameworks (stuff like libraries or ways to build APIs) and other tools an organization uses to build web applications.

Our goal at the PSC is to build a modern testing platform to replace the paper “in-basket” tests given to those applying for management positions with the Government of Canada. It’s a big job, and we’re given nine months to do it. That’s nine months to scope a problem, conduct user research, and build (and iterate on) a tool.

We knew we couldn’t build something great in that timeframe using the PSC’s existing tech stack. Their suite of tools lacked automated testing, were not browser-based and deployed to production less frequently than we planned to.

So, with the help of our team at PSC, we set about trying to change things.

I’ll admit that we may have been a bit naive about the scope of that task. The PSC had not introduced a new tech stack in over 15 years. Some people were skeptical, but many of our colleagues saw that these new tools would benefit far more than just our one project.

But introducing new technology into the federal government is no small feat. IT decisions affect several organizations within a department, each with their own needs and existing limitations. There’s also no shortage of legacy systems in government, which depend on existing software. To get the tools we needed, we had to navigate numerous approvals, buy-ins and signoffs. The true scope of what we were trying became clear only after we started, but given our project goals, the only way around was through.

The good news is that with a lot of help from some champions at the PSC, we got it done! For the first time in nearly two decades, Canada’s Public Service Commission has updated its tech stack to include modern tools likeReactJS, Django and Docker. And now we are confident that we can build something awesome based on that foundation. In fact, we already have a prototype working on a private cloud (an instance of Azure Stack provided by Shared Services Canada), which will allow the PSC to invest in an automated cloud pipeline.

The proposed tech stack at the PSC included the following. Developer tools: VSCode and GitHub; Front end: ReactJS; Back end: Django; Database: PostgreSQL; Server: Nginx; OS: Linux; Containers: Docker.
The proposed tech stack at the PSC included the following. Developer tools: VSCode and GitHub; Front end: ReactJS; Back end: Django; Database: PostgreSQL; Server: Nginx; OS: Linux; Containers: Docker.

So, we did it. And that means you can too. If you’re in government and looking to introduce a new technology stack, here’s a bit about how we got it done and what we learned along the way.

Make your case

Like any change project, getting approval for a new tech stack will rest on your ability to show how new tools will enable or accelerate your organization’s goals. We based our argument on four key pillars:

  • Accessibility: Many modern development tools were built with accessibility in mind. This means that adopting them makes it easier to implement current accessibility standards and improve the experience of your products and services for all users in general, and those with disabilities in particular.
  • Talent: Developers typically want to work with the latest languages and frameworks. Having a modern tech stack can make your organization a more attractive employer.
  • Resources: Modern tools make it easier to build — and more importantly test — complex user interfaces, and they’re better suited to environments where you’re iterating and deploying often. These tools can reduce the time it takes staff to implement changes and also helps your team be more agile.
  • Simplicity and security: By adopting common, and often open source, tech tools, you’re less likely to have to reinvent the wheel to implement new features. Similarly, open source software is often more secure, and has a proven track record of success that you can rely on.

Empathize with your environment

We started at the PSC by talking to people. Asking what works for them and what they need to make it better. We had a lot of coffees and lunches, but it was worth it; it not only helped us build our case, but also communicated to our colleagues that we wanted to amplify the innovative work that was already happening at the PSC, and not just change things for the sake of it.

Through this process, we learned that the PSC IT team really valued security (and for good reason, as the PSC handles a lot of sensitive assessment data) but was struggling to ensure the organization had the agility to patch any issues as quickly as possible.

We also learned about initiatives at the PSC that could get a boost from a new tech stack. In particular, we heard there was a desire to adopt moreopen source software and find ways to automate common IT processes.

We made sure these needs were addressed in our pitch. We also customized pitches for different stakeholders. For example, we spoke to Director and Executive level teams about talent pools in the job market and how a new tech stack can make them an attractive employer, and to the IT team about how frequent updates to software versions can make a product more secure.

Do your homework

The two developers on our team at the PSC did the research to determine what stack we would propose. Together we came up with a robust set of parameters and considered a number of options for the backend, frontend, database, and web server. We were much more likely to gain buy-in once people saw how much research was done, so we began to incorporate the document into our presentations.

From there, we picked our top three tools for each category and did more in-depth research. After looping in stakeholders again, this became a two-page final proposal for our stack. By this point, many of our stakeholders were on-side because they were part of the proposal process.

We also read up on TBS policy related to IT. The Canadian Digital Service was a huge help to us early on to understand this policy and how to best utilize it. We made sure to reference it as much as possible when making proposals, and we found stakeholders appreciated that we were grounding our asks in their policy context.

Map your path to success

The federal approvals process for introducing new technology is quite complex, and we definitely made things more difficult for ourselves by not understanding how some of the steps on the approval ladder worked (or in some cases, being ignorant that they existed). So we decided to map out the entire process to get a clear picture of the steps and stakeholders involved. In our case, we needed approvals from the Architectural Review Committee, the Change Acceptance Board, and the Executive Director Manager Committee. Our final step is to present to the Government of Canada Enterprise Architecture Review Board.

Our “Path to Success”
Our “Path to Success”

Once we created this map, and could see the process, it was much easier to think strategically about who we needed support from and when.

Find your champions and enable them

This may sound obvious, but the more supporters you can get, the better. A big win for us was getting our partners on the business team to understand the value a new tech stack can bring. While they aren’t the decision makers, they are the client for the IT department, and their support was meaningful.

We went over the basics of a web application with our business team and how our stack mapped to each part of this system so they could be champions for this change too.
We went over the basics of a web application with our business team and how our stack mapped to each part of this system so they could be champions for this change too.

Once you’ve found your champions, we tried to make it easy for them to explain the value of a new tech stack to other stakeholders and project members. We created a “master slide deck” and shared it so that anyone else could pull from to make a presentation. This was especially useful when we were unable to present to senior stakeholders directly; all the documentation was readily available so senior project members could make the case on our behalf.

Don’t be afraid to experiment

If you’re a developer, you know the importance of having a sandbox to try things out. But the challenge in government is that until you get approval for your new stack, you likely won’t have any permissions to install anything and try it out.

This is where you need to get creative. I utilized open source software, and my personal computer and got a prototype working. Then I pushed this toGitHub so that the only thing blocking us internally was approvals, and admin rights to install software. It’s entirely possible to build a prototype without using any confidential data or information, and having a working demo to show people created a lot of momentum and helped us to get buy-in.

If you’ve made it this far, thank you for reading! We hope our success and our learnings can help inspire others to push for new technology stacks in their organizations. If you’re engaged in that process, we’d love to connect. Drop me a line at caley@cfc-dev.loafingshed.ca!

Lastly, while the Code for Canada fellows may have been a catalyst for change, the folks at the PSC did most of this work, and will ultimately take on the benefits. We’re grateful for the support we’ve received from PSC leadership, including Mathieu Kralj, Jean-Francois Filion, and Elizabeth Rhodenizer, as well Francis Normand and Michael Cherry from our dev team! We’re thrilled to share this win with you, and we’re excited to see how you, and everyone at the Public Service Commission takes this new technology forward into the future.

Introduction d’une nouvelle infrastructure technologique au gouvernement

Comment les fellows (associés) de Code for Canada ont aidé la Commission de la fonction publique du Canada à moderniser ses outils de développement

(De gauche Ă  droite) Les fellows de Code for Canada Siobhan, Joey et Caley ont travaillĂ© avec la Commission de la fonction publique du Canada Ă  moderniser les outils d’évaluation des postes dont elle se sert.
(De gauche Ă  droite) Les fellows de Code for Canada Siobhan, Joey et Caley ont travaillĂ© avec la Commission de la fonction publique du Canada Ă  moderniser les outils d’évaluation des postes dont elle se sert.

En tant que fellows de Code for Canada, nous avons deux missions parallĂšles : livrer un excellent produit ou service et mettre en commun de maniĂšre ouverte nos outils et nos processus avec nos collĂšgues du gouvernement. Ces buts s’avĂšrent souvent insĂ©parables, car la livraison de produits intuitifs et adaptĂ©s aux besoins de vos utilisateurs exige de repenser la conception de ces produits.

Pour vous montrer de quelle façon ces deux concepts — la chose que vous concevez et la maniĂšre dont vous le faites — sont liĂ©s, laissez-moi vous expliquer comment notre Ă©quipe du programme de fellowship s’y est prise pour aider Ă  introduire une nouvelle infrastructure technologique Ă  la Commission de la fonction publique du Canada (CFP). Si vous ne connaissez pas bien ce terme, sachez qu’une « infrastructure technologique », c’est l’ensemble de langages logiciels (comme JavaScript, Python ou Ruby), de cadres (par exemple, des bibliothĂšques ou des façons de crĂ©er des interfaces de programmation d’applications, ou API en anglais) et d’autres outils utilisĂ©s par une organisation afin de dĂ©velopper des applications Web.

À la CFP, notre objectif Ă©tait de dĂ©velopper une plateforme d’évaluation moderne qui remplacerait les Ă©valuations papier de type « Ă©preuve du courrier », ou « test in-basket » (en anglais seulement) auxquelles sont soumis les candidats Ă  des postes de gestion au gouvernement fĂ©dĂ©ral. Il s’agissait d’un gros mandat, et nous avons eu neuf mois pour le remplir. Neuf mois donc pour cerner le problĂšme, mener une recherche sur les utilisateurs et dĂ©velopper un outil (et le retravailler).

Nous savions que nous ne pouvions pas concevoir un excellent produit dans ce laps de temps Ă  partir de l’infrastructure technologique qui Ă©tait en place Ă  la CFP. Les diffĂ©rents outils utilisĂ©s par la CFP ne comprenaient pas suffisamment de tests automatisĂ©s, ne se basaient pas sur un navigateur et Ă©taient dĂ©ployĂ©s moins frĂ©quemment dans l’environnement de production que ce que vous avions prĂ©vu.

Par consĂ©quent, nous avons dĂ©cidĂ© d’essayer de remĂ©dier Ă  la situation avec le concours de notre Ă©quipe Ă  la CFP.

Je dois admettre que nous avons peut-ĂȘtre Ă©tĂ© un peu naĂŻfs concernant l’ampleur de la tĂąche. La CFP n’avait pas introduit de nouvelle infrastructure technologique depuis plus de 15 ans. Certaines personnes Ă©taient sceptiques, mais un grand nombre de nos collĂšgues considĂ©raient que ces nouveaux outils s’avĂ©reraient utiles pour bien d’autres projets par la suite.

Cependant, rĂ©ussir Ă  introduire une nouvelle technologie au gouvernement fĂ©dĂ©ral ne constitue pas un mince exploit. Les dĂ©cisions relatives aux TI ont une incidence sur plusieurs organisations dans un ministĂšre, chacune ayant ses besoins et ses contraintes propres. De plus, quantitĂ© de systĂšmes patrimoniaux au gouvernement reposent sur les logiciels existants. Pour obtenir les outils dont nous avions besoin, nous avons eu Ă  effectuer de nombreuses demandes d’approbation, d’acquisition et de signature. La portĂ©e rĂ©elle de ce que nous avons essayĂ© de mettre en place n’est devenue claire qu’une fois que nous avons commencĂ©, mais, Ă©tant donnĂ© les objectifs de notre projet, la seule solution Ă©tait de foncer.

La bonne nouvelle est que, avec beaucoup d’aide de la part de certains champions de la CFP, nous avons rĂ©ussi! Pour la premiĂšre fois depuis prĂšs de deux dĂ©cennies, la CFP a mis Ă  jour son infrastructure technologique afin d’y inclure des outils modernes comme ReactJS, Django (en anglais seulement) et Docker (en anglais seulement). Maintenant, nous sommes sĂ»rs que nous pouvons dĂ©velopper des outils formidables sur cette base. En effet, nous avons dĂ©jĂ  un prototype fonctionnel dans un nuage Azure hĂ©bergĂ© par Services partagĂ©s Canada, ce qui permettra Ă  la CFP d’investir dans un pipeline infonuagique automatisĂ©.

L’infrastructure technologique proposĂ©e Ă  la CFP comprend les Ă©lĂ©ments suivants : VSCode et GitHub comme outils de dĂ©veloppement; ReactJS comme application frontale; Django comme application dorsale; une base de donnĂ©es PostgreSQL; Nginx comme serveur; le systĂšme d’exploitation Linux et Docker comme conteneur.
L’infrastructure technologique proposĂ©e Ă  la CFP comprend les Ă©lĂ©ments suivants : VSCode et GitHub comme outils de dĂ©veloppement; ReactJS comme application frontale; Django comme application dorsale; une base de donnĂ©es PostgreSQL; Nginx comme serveur; le systĂšme d’exploitation Linux et Docker comme conteneur.

Nous pouvons maintenant dire « mission accomplie ». Vous pouvez donc le faire, vous aussi. Si vous travaillez au gouvernement et que vous envisagez d’intĂ©grer une nouvelle infrastructure technologique, laissez-moi d’abord vous prĂ©sentez briĂšvement de quelle maniĂšre nous y sommes parvenus et ce que nous avons appris en cours de route.

Faire valoir ses idées

Comme pour n’importe quel projet de changement, vous obtiendrez les approbations requises pour une nouvelle infrastructure technologique si vous ĂȘtes capable de dĂ©montrer comment de nouveaux outils faciliteraient ou accĂ©lĂ©reraient l’atteinte des objectifs de votre organisation. Dans notre cas, nous avions basĂ© notre argumentation sur les quatre principes clĂ©s qui suivent :

  • AccessibilitĂ© : Un grand nombre d’outils de dĂ©veloppement contemporains ont Ă©tĂ© conçus en ayant l’accessibilitĂ© en tĂȘte. Autrement dit, l’utilisation de ces outils permet de satisfaire plus facilement aux normes actuelles en matiĂšre d’accessibilitĂ© et d’amĂ©liorer l’expĂ©rience de tous les utilisateurs de vos produits et services en gĂ©nĂ©ral et, surtout, de ceux ayant des incapacitĂ©s.
  • Talent : Les dĂ©veloppeurs veulent habituellement travailler avec les langages et les cadres les plus rĂ©cents. Le fait de possĂ©der une infrastructure moderne peut faire de votre organisation un employeur plus attrayant.
  • Ressources : Les outils contemporains facilitent la conception — et surtout la mise Ă  l’essai — des interfaces utilisateur complexes, et ils conviennent mieux aux environnements dans lesquels on rĂ©pĂšte et dĂ©ploie souvent des solutions informatiques. Ces outils peuvent rĂ©duire le temps que prend votre effectif pour mettre en Ɠuvre des changements et aident aussi votre Ă©quipe Ă  gagner en souplesse.
  • SimplicitĂ© et sĂ©curitĂ© : En adoptant des outils technologiques communs, et souvent libres, vous ĂȘtes moins susceptible de devoir rĂ©inventer la roue quand vous voulez mettre en Ɠuvre de nouvelles fonctionnalitĂ©s. Par ailleurs, les logiciels libres sont souvent plus sĂ©curitaires et ils ont connu de nombreux succĂšs qui font que vous pouvez vous fier Ă  eux.

Bien connaĂźtre son environnement

À la CFP, nous avons commencĂ© par parler avec les gens, en leur demandant ce qui fonctionnait pour eux et ce qu’ils devaient amĂ©liorer. Nous avons pris beaucoup de cafĂ©s et organisĂ© une multitude de dĂźners de travail, mais cela en a valu la peine, car nous avons rĂ©ussi ainsi non seulement Ă  monter notre dossier, mais aussi Ă  communiquer Ă  nos collĂšgues que nous voulions donner plus d’ampleur aux travaux d’innovation dĂ©jĂ  en cours Ă  la CFP, et non pas simplement changer les choses juste pour les faire autrement.

Durant le processus, nous avons appris que l’équipe des TI de la CFP accordait une grande importance Ă  la sĂ©curitĂ© (pour de bonnes raisons, Ă©tant donnĂ© que la CFP gĂšre beaucoup de donnĂ©es d’évaluation de nature dĂ©licate), mais Ă©prouvait de la difficultĂ© Ă  s’assurer que l’organisation avait la souplesse requise pour apporter des correctifs aux problĂšmes le plus rapidement possible.

Nous en avons aussi appris plus au sujet des initiatives Ă  la CFP susceptibles de bĂ©nĂ©ficier d’une nouvelle infrastructure technologique. Plus prĂ©cisĂ©ment, nous avons constatĂ© que nos collĂšgues souhaitaient adopter davantage de logiciels libres (en anglais seulement) et trouver des façons d’automatiser les processus de TI communs.

Nous avons veillĂ© Ă  traiter des besoins exprimĂ©s par nos collĂšgues dans notre prĂ©sentation et nous avons Ă©galement adaptĂ© nos prĂ©sentations aux divers intervenants. Par exemple, nous avons parlĂ© aux Ă©quipes de directeurs et de hauts fonctionnaires des rĂ©serves de talents sur le marchĂ© du travail et de quelle maniĂšre une nouvelle infrastructure technologique pouvait faire de leur organisation un employeur attrayant pour les chercheurs d’emploi. De plus, nous avons fait valoir Ă  l’équipe des TI dans quelle mesure les mises Ă  jour frĂ©quentes des versions de ses logiciels pouvaient mieux protĂ©ger un produit.

Se préparer

Les deux dĂ©veloppeurs dans notre Ă©quipe Ă  la CFP ont menĂ© la recherche pour dĂ©terminer quelle infrastructure nous allions proposer. Ensemble, nous avons trouvĂ© un ensemble de paramĂštres trĂšs fiables, et nous avons considĂ©rĂ© un certain nombre d’options pour les applications frontales et dorsales, la base de donnĂ©es et le serveur Web. Puisque nous avions plus de chance d’obtenir l’adhĂ©sion des membres notre auditoire une fois qu’ils auraient vu la quantitĂ© de recherches effectuĂ©es, nous avons commencĂ© Ă  intĂ©grer le document Ă  nos prĂ©sentations.

Ensuite, nous avons sĂ©lectionnĂ© nos trois outils les plus performants pour chacune des catĂ©gories et nous avons menĂ© d’autres recherches approfondies. AprĂšs avoir intĂ©grĂ© les intervenants de nouveau, notre projet a pris la forme d’un document de deux pages qui prĂ©sentait notre proposition finale d’infrastructure technologique. À ce stade-ci, un grand nombre des intervenants Ă©taient de notre cĂŽtĂ©, car ils avaient pris part Ă  l’élaboration de la proposition.

Nous avons aussi pris connaissance de la politique du SCT relative aux TI. DĂšs le dĂ©but, le Service numĂ©rique canadien nous a Ă©tĂ© d’un grand secours pour comprendre la politique et choisir la meilleure façon de l’utiliser. Nous nous sommes assurĂ©s de nous y reporter le plus possible quand nous prĂ©sentions nos propositions, et nous avons dĂ©couvert que les intervenants nous ont Ă©tĂ© reconnaissants d’avoir fondĂ© nos demandes sur leur contexte stratĂ©gique.

Planifier votre cheminement vers la réussite

Le processus fĂ©dĂ©ral d’approbation pour l’introduction d’une nouvelle technologie est assez complexe, et nous avons assurĂ©ment rendu les choses plus difficiles pour nous en ne comprenant pas le fonctionnement de certaines des Ă©tapes de ce processus (ou dans certains cas, en ignorant leur existence). Nous avons donc dĂ©cidĂ© de schĂ©matiser tout le processus afin d’obtenir un portrait clair des Ă©tapes et des intervenants impliquĂ©s. Dans notre cas, nous avons eu besoin d’approbations de la part du ComitĂ© d’examen de l’architecture (CEA), du comitĂ© consultatif sur les changements (CCC) et du comitĂ© des directeurs gĂ©nĂ©raux et des gestionnaires. La derniĂšre Ă©tape consistait Ă  prĂ©senter notre projet au Conseil d’examen de l’architecture intĂ©grĂ©e du GC.

Notre « cheminement vers le succÚs »
Notre « cheminement vers le succÚs »

DÚs que nous avons créé ce schéma, et que nous pouvions visualiser le processus, il était bien plus facile de réfléchir de maniÚre stratégique à qui nous devions demander du soutien et quand.

Trouver ses champions et les outiller

Cela peut sembler ĂȘtre une Ă©vidence, mais plus vous obtenez d’appui, mieux c’est. Il s’agissait d’une grande victoire pour nous quand nous avons rĂ©ussi Ă  intĂ©grer nos partenaires Ă  l’équipe opĂ©rationnelle afin qu’ils comprennent les avantages Ă  retirer d’une nouvelle infrastructure technologique. MĂȘme s’ils ne faisaient pas partie des dĂ©cideurs, ils Ă©taient les clients du service des TI, et leur soutien Ă©tait important.

Nous avons parcouru les Ă©lĂ©ments de base d’une application Web avec les membres de notre Ă©quipe opĂ©rationnelle et les liens entre chaque partie du systĂšme dans notre infrastructure afin qu’ils puissent aussi ĂȘtre des champions concernant ce changement.
Nous avons parcouru les Ă©lĂ©ments de base d’une application Web avec les membres de notre Ă©quipe opĂ©rationnelle et les liens entre chaque partie du systĂšme dans notre infrastructure afin qu’ils puissent aussi ĂȘtre des champions concernant ce changement.

Une fois que nous avons trouvĂ© nos champions, nous avons essayĂ© de rendre cela facile pour eux d’expliquer aux autres intervenants et membres du projet quels Ă©taient les avantages qu’offrait une nouvelle infrastructure. Nous avons crĂ©Ă© une « prĂ©sentation PowerPoint principale » et nous l’avons rendu accessible de façon Ă  ce que n’importe qui puisse s’en servir pour faire une prĂ©sentation. Cette initiative s’est avĂ©rĂ©e particuliĂšrement utile lorsque nous avons Ă©tĂ© incapables de prĂ©senter directement notre projet aux intervenants principaux, car toute la documentation Ă©tait ainsi Ă  la disposition des principaux membres du projet, qui ont pu plaider en faveur de nos idĂ©es pour nous.

Ne pas avoir peur d’expĂ©rimenter

Si vous ĂȘtes un dĂ©veloppeur, vous savez comme il est important d’avoir un bac Ă  sable pour tester des programmes et des donnĂ©es. Cependant, la difficultĂ© au gouvernement est que, tant que votre nouvelle infrastructure n’aura pas Ă©tĂ© approuvĂ©e, vous ne serez probablement pas autorisĂ© Ă  installer et Ă  tester quoi que ce soit.

C’est Ă  ce stade-ci qu’il faut faire preuve de crĂ©ativitĂ©. À l’aide de logiciels libres et de mon ordinateur personnel, j’ai rĂ©ussi Ă  faire fonctionner un prototype. Ensuite, je l’ai transfĂ©rĂ© sur la plateforme GitHub. La seule chose qui nous faisait alors encore obstacle Ă  l’interne, c’était d’obtenir les approbations et droits d’administrateur qui nous permettraient d’installer des logiciels. Il est tout Ă  fait possible de concevoir un prototype sans se servir de donnĂ©es ou d’information confidentielles, et le fait d’avoir un dĂ©mo fonctionnel Ă  montrer aux gens donne de l’élan au projet et aide Ă  obtenir de l’appui.

Si vous vous ĂȘtes rendu aussi loin, nous vous remercions de nous avoir lus! Nous espĂ©rons que le rĂ©cit de nos succĂšs et de nos apprentissages contribuera Ă  en inspirer d’autres Ă  soutenir l’introduction de nouvelles infrastructures technologiques dans leur organisation. Si vous ĂȘtes en cours de processus pour y parvenir, nous serions ravis d’avoir de vos nouvelles. Envoyez-moi un courriel Ă  caley@cfc-dev.loafingshed.ca!

En conclusion, mĂȘme si les fellows de Code for Canada ont peut-ĂȘtre Ă©tĂ© un moteur de changement, nos collĂšgues de la CFP ont fait la majoritĂ© du travail et ce sont eux ultimement qui en tireront profit. Nous sommes reconnaissants de l’appui que nous avons reçu de la part de la direction de la CFP, notamment de Mathieu Kralj, Jean-François Filion et Elizabeth Rhodenizer, ainsi que de Francis Normand et Michael Cherry de notre Ă©quipe de dĂ©veloppement! Nous sommes ravis de vous communiquer ce succĂšs, et nous avons hĂąte de voir de quelle façon vous et tous ceux Ă  la CFP ferez Ă©voluer cette nouvelle technologie par la suite.