diff --git a/README.md b/README.md
index 90bef81..c6a0df4 100644
--- a/README.md
+++ b/README.md
@@ -64,8 +64,8 @@ Pour l'exercice d'ébauche, le format du Standard a été utilisé pour commence
* [Guides](fr/guides)
* [Utilisation de logiciels libres](fr/guides/utilisation-logiciels-libres.md)
- * [Contribution aux logiciels libres](fr/guides/contribution-à-des-logiciels-libres.md)
- * [Publication de code source libre](fr/guides/publication-code-source-ouvert.md)
+ * [Contribution aux logiciels libres](fr/guides/contribution-logiciels-libres.md)
+ * [Publication de code source libre](fr/guides/publication-code-source-libre.md)
## Traduction
diff --git a/_config.yml b/_config.yml
index 8e7f415..1caa55a 100644
--- a/_config.yml
+++ b/_config.yml
@@ -94,12 +94,12 @@ defaults:
ref: "home"
-
scope:
- path: "fr/guides/cas-conceptuel-pour-logiciels-libres.md"
+ path: "fr/guides/importance-cas-conceptuel.md"
values:
ref: "starting"
-
scope:
- path: "fr/guides/acquerir-logiciels-libres.md"
+ path: "fr/guides/acquisition-logiciels-libres.md"
values:
ref: "acquisition"
-
@@ -109,12 +109,12 @@ defaults:
ref: "using"
-
scope:
- path: "fr/guides/contribution-à-des-logiciels-libres.md"
+ path: "fr/guides/contribution-logiciels-libres.md"
values:
ref: "contributing"
-
scope:
- path: "fr/guides/publication-code-source-ouvert.md"
+ path: "fr/guides/publication-code-source-libre.md"
values:
ref: "publishing"
- scope:
diff --git a/_data/i18n/general.yml b/_data/i18n/general.yml
index c218553..8cda8ea 100644
--- a/_data/i18n/general.yml
+++ b/_data/i18n/general.yml
@@ -52,13 +52,13 @@ nav:
fr: Élaborer un cas conceptuel pour Open Source
link:
en: /en/guides/importance-of-concept-case.html
- fr: /fr/guides/cas-conceptuel-pour-logiciels-libres.html
+ fr: /fr/guides/importance-cas-conceptuel.html
acquisition:
en: Guide for Open Source Software Acquisition
fr: Guide pour l'acquisition des logiciels libres
link:
en: /en/guides/guide-for-acquisition.html
- fr: /fr/guides/acquerir-logiciels-libres.html
+ fr: /fr/guides/acquisition-logiciels-libres.html
using:
en: Use of Open Source Software
fr: Guide sur l'utilisation des logiciels libres
@@ -70,13 +70,13 @@ nav:
fr: Guide sur la contribution à des logiciels libres
link:
en: /en/guides/contributing-to-open-source-software.html
- fr: /fr/guides/contribution-à-des-logiciels-libres.html
+ fr: /fr/guides/contribution-logiciels-libres.html
publishing:
en: Publication of Open Source Code
- fr: Guide sur la publication de code source ouvert
+ fr: Guide de publication de code source libre
link:
en: /en/guides/publishing-open-source-code.html
- fr: /fr/guides/publication-code-source-ouvert.html
+ fr: /fr/guides/publication-code-source-libre.html
definitions:
en: Definitions
fr: Définitions
diff --git a/cspell.json b/cspell.json
index 14f0858..cf61732 100644
--- a/cspell.json
+++ b/cspell.json
@@ -1,58 +1,89 @@
{
"version": "0.1",
- "language": "en",
+ "language": "fr",
"words": [
- "IMSO",
- "framagit",
- "agpl",
- "lgpl",
- "gpl",
- "ised",
- "pspc",
- "bitbucket",
- "gccode",
- "ccode",
- "eupl",
- "licenced",
- "unilingual",
- "auditable",
- "markdownlint",
- "cddl",
- "Québec",
- "Réciprocité",
- "rplus",
- "CILL",
- "cecill",
- "discoverability",
- "cpal",
- "affero",
- "nposl",
- "ogtsl",
- "apsl",
- "catosl",
- "datagrid",
- "entessa",
- "frameworx",
- "lppl",
- "motosoto",
- "naumen",
- "nethack",
- "ngpl",
- "cnri",
- "rpsl",
- "oclc",
- "rscpl",
- "sleepycat",
- "sybase",
- "watcom",
- "vovida",
- "xwindows",
- "zope",
- "sissl",
- "oset"
+ "IMSO",
+ "framagit",
+ "agpl",
+ "lgpl",
+ "gpl",
+ "ised",
+ "pspc",
+ "bitbucket",
+ "gccode",
+ "ccode",
+ "eupl",
+ "licenced",
+ "unilingual",
+ "auditable",
+ "markdownlint",
+ "cddl",
+ "Québec",
+ "Réciprocité",
+ "rplus",
+ "CILL",
+ "cecill",
+ "discoverability",
+ "cpal",
+ "affero",
+ "nposl",
+ "ogtsl",
+ "apsl",
+ "catosl",
+ "datagrid",
+ "entessa",
+ "frameworx",
+ "lppl",
+ "motosoto",
+ "naumen",
+ "nethack",
+ "ngpl",
+ "cnri",
+ "rpsl",
+ "oclc",
+ "rscpl",
+ "sleepycat",
+ "sybase",
+ "watcom",
+ "vovida",
+ "xwindows",
+ "zope",
+ "sissl",
+ "oset",
+ "Canada’s",
+ "project’s",
+ "artifact",
+ "project’s",
+ "institution’s",
+ "lacceptation",
+ "puisqu’il",
+ "Lorsqu’une",
+ "sinscrire",
+ "Lorsqu’on",
+ "plugiciels",
+ "contribués",
+ "lorsqu’il",
+ "lorsqu’ils",
+ "ISDE",
+ "SPAC",
+ "plugiciels",
+ "lorsqu’un",
+ "découvrabilité",
+ "Queen’s",
+ "fide",
+ "endeavor",
+ "lorsqu’acceptées",
+ "lintermédiaire",
+ "léchange"
],
- "flagWords": [],
+ "import": ["./node_modules/cspell-dict-fr-fr/cspell-ext.json"],
"dictionaries": [
- "en-gb"
+ "fr-fr",
+ "en-gb",
+ "en_US",
+ "typescript",
+ "softwareterms",
+ "html",
+ "css"
]
-}
+}
\ No newline at end of file
diff --git a/en/guides/contributing-to-open-source-software.md b/en/guides/contributing-to-open-source-software.md
index aedb505..56ab59f 100644
--- a/en/guides/contributing-to-open-source-software.md
+++ b/en/guides/contributing-to-open-source-software.md
@@ -14,20 +14,20 @@ Even simply supporting the contributions of others, or expressing interest in an
The steps for GC to contribute code to open source software communities are:
-1. [Verify Open Source Software Licence](#verify-open-source-software-licence)
-2. [Verify Contributing Process and Policies](#verify-contributing-process-and-policies)
-3. [Additional Approvals](#additional-approvals)
-4. [Contribute to the project](#contribute-to-the-project)
-5. [Contribute through professional services](#contribute-through-professional-services)
-6. [Publish contributions regardless of upstream acceptance](#publish-contributions-regardless-of-upstream-acceptance)
+1. [Verify Open Source Software Licence](#1-verify-open-source-software-licence)
+2. [Verify Contributing Process and Policies](#2-verify-contributing-process-and-policies)
+3. [Additional Approvals](#3-additional-approvals)
+4. [Contribute to the project](#4-contribute-to-the-project)
+5. [Contribute through professional services](#5-contribute-through-professional-services)
+6. [Publish contributions regardless of upstream acceptance](#6-publish-contributions-regardless-of-upstream-acceptance)
-## Verify Open Source Software Licence
+## 1. Verify Open Source Software Licence
The GC can contribute to all software licensed under an [Open Source Initiative approved license](https://opensource.org/licenses) or a [Free Software Foundation free software licence](https://www.gnu.org/licenses/license-list.html).
If a licence for software developed in the open is under another licence, seek legal counsel to clarify if contributions are recommended.
-## Verify Contributing Process and Policies
+## 2. Verify Contributing Process and Policies
Certain projects may have specific policies for code contribution (Contributor Licence Agreement, Developer's Certificate of Origin) as well as processes (templates, platform, etc.).
Before going forward with submitting a contribution, employees should properly understand the project contribution processes and policies.
@@ -55,7 +55,7 @@ It usually consist of adding a "Signed by: contributor@email.com" in the commit
Unlike for a CLA, if you do have the right to submit a contribution, a DCO should not cause a problem as you should have already acquired the proper approvals to contribute to the project.
See [Additional Approvals](#additional-approvals)
-## Additional Approvals
+## 3. Additional Approvals
If for some reason the departmental delegated approvals are not meeting the third-party contribution's requirements, employees should contact their supervisor to see how they can obtain the additional approvals required.
Departments should define specific criteria for approval of open-source contributions, and describe them clearly to employees.
@@ -71,7 +71,7 @@ Similar to open data or information covered by the [Directive on Open Government
That person may vary according to your department and delegation should be encouraged to the lowest level possible to encourage contribution to 3rd party OSS projects.
-## Contribute to the project
+## 4. Contribute to the project
### Identify as an employee of the Government of Canada
@@ -92,11 +92,11 @@ This way, your changes will help improve the software for everyone that uses it
Contributing to a 3rd party should be done in accordance to the project governance model, if such a model is present.
-## Contribute through professional services
+## 5. Contribute through professional services
If your department would like to leverage professional services to contribute to third party projects, see [Obtain Rights to Custom Code in Contracts](publishing-open-source-code.md#obtain-rights-to-custom-code-in-contracts)
-## Publish contributions regardless of upstream acceptance
+## 6. Publish contributions regardless of upstream acceptance
Whether or not a given set of changes is accepted upstream as a contribution, the changes should still be published in accordance with the [Guide for Publishing Open Source Code](https://github.com/canada-ca/open-source-logiciel-libre/blob/master/en/guides/publishing-open-source-code.md).
diff --git a/en/guides/importance-of-concept-case.md b/en/guides/importance-of-concept-case.md
index 0245c18..0cdfe2d 100644
--- a/en/guides/importance-of-concept-case.md
+++ b/en/guides/importance-of-concept-case.md
@@ -20,13 +20,13 @@ The Directive on [Policy on the Planning and Management of Investments, Appendix
The Use of International or Canadian Standards
-Business Requirements may dictate that the underlying application should conform to International or Canadian Standards, such as but not limited to requirement that the official languages requiring Software be available in both official languages.
+Business Requirements may dictate that the underlying application should conform to International or Canadian Standards, such as but not limited to the requirement that the Software be available in both official languages.
Flexibility of the License
Open Source Software licenses can provide more flexibility than a proprietary license for a digital project’s deliverables.
-Where the Business Requirement would benefit from the reuse of Software, the GC may acquire Software such that it may be used in subsequent projects in the GC. A Proprietary Software licensor can grant such right of re-use upon request, but by its nature, all Open Source Software is reusable and therefore compliant with this request by default.
+Where the Business Requirement would benefit from the reuse of Software, the GC may acquire Software such that it may be used in subsequent projects. A Proprietary Software licensor can grant such right of re-use upon request, but by its nature, all Open Source Software is reusable and therefore compliant with this request by default.
Ability to use for any Purpose
@@ -38,7 +38,7 @@ The Directive on [Policy on the Planning and Management of Investments, Appendix
The Alignment with Open Government
-In addition the GC may set its requirements such that the source code be provided to the public to enable greater transparency and align with Open Government principles of the D9.
+In addition the GC may set its requirements such that the source code be provided to the public to enable greater transparency and align with Open Government principles of the D9.
The Ability to Distribute the Software
diff --git a/en/guides/publishing-open-source-code.md b/en/guides/publishing-open-source-code.md
index 51229b0..6bda369 100644
--- a/en/guides/publishing-open-source-code.md
+++ b/en/guides/publishing-open-source-code.md
@@ -10,16 +10,16 @@ When releasing the code at large is not appropriate, or possible, it is recommen
The steps to publish GC source code are:
-1. [Seek Approvals](#seek-approvals)
-2. [Obtain Rights to Custom Code in Contracts](#obtain-rights-to-custom-code-in-contracts)
-3. [Consider Security Implications](#consider-security-implications)
-4. [Select Open Source Software Licence](#select-open-source-software-licence)
-5. [Select Source Code Repository](#select-source-code-repository)
-6. [Add Recommended Files](#add-recommended-files)
-7. [Publishing a Legacy Application](#publishing-a-legacy-application)
-8. [Work in the Open](#work-in-the-open)
+1. [Seek Approvals](#1-seek-approvals)
+2. [Obtain Rights to Custom Code in Contracts](#2-obtain-rights-to-custom-code-in-contracts)
+3. [Consider Security Implications](#3-consider-security-implications)
+4. [Select Open Source Software Licence](#4-select-open-source-software-licence)
+5. [Select Source Code Repository](#5-select-source-code-repository)
+6. [Add Recommended Files](#6-add-recommended-files)
+7. [Publishing a Legacy Application](#7-publishing-a-legacy-application)
+8. [Work in the Open](#8-work-in-the-open)
-## Seek Approvals
+## 1. Seek Approvals
### Team
@@ -37,7 +37,7 @@ Similar to open data or information covered by the [Directive on Open Government
That person may vary according to your department and delegation should be encouraged to the lowest level possible to encourage the release of open source code.
-## Obtain Rights to Custom Code in Contracts
+## 2. Obtain Rights to Custom Code in Contracts
The ISED [Policy on Title to Intellectual Property Arising Under Crown Procurement Contracts](https://www.ic.gc.ca/eic/site/068.nsf/eng/00005.html) provides that the contractor is to own the rights to foreground intellectual property (IP) created as a result of a Crown procurement contract.
But when the Crown's intended use of the IP can be met through licence arrangements, it has the opportunity to seek the needed licence(s) whether broad or narrow.
@@ -46,7 +46,7 @@ As part of the discussion with the institution’s legal services unit and the c
Departments or agencies are able to release code developed as a result of a Crown procurement contract under an open source software licence where such rights have been granted to Canada. The procurement contract could also require that the contracting body be responsible for publishing the source code under an acceptable open source software licence or contribute directly to existing open source software using that project's licence, and such clauses would be effective where agreed to by the supplier.
-## Consider Security Implications
+## 3. Consider Security Implications
### Developing Software in the Open
@@ -58,7 +58,7 @@ Departments or agencies are able to release code developed as a result of a Crow
- Embed security practices in your daily processes and methodologies.
- Leverage tools and services to automate finding known security vulnerabilities, possible secret keys and personally identifiable information.
-## Select Open Source Software Licence
+## 4. Select Open Source Software Licence
When the project is part of a larger open source software community, like plugins, modules, extensions, or derivative works of existing open source software, it is highly recommended to use the license which is usually used by the community.
@@ -181,7 +181,7 @@ Replace the **(legal departmental name)** and **(year of publication)** with the
This notice should be added to the `LICENCE` file in your project. See [Add Recommended Files](#add-recommended-files)
-## Select Source Code Repository
+## 5. Select Source Code Repository
Recommended public source code repositories for Government of Canada open source code are:
@@ -204,7 +204,7 @@ This would help discoverability of your projects but also help increase collabor
The recommended version control system for GC open source code is Git.
Departments are also encouraged to use Git to manage their source code internally.
-## Add Recommended Files
+## 6. Add Recommended Files
Before publishing, source code should include the following file:
@@ -224,7 +224,7 @@ Additionally, the following are recommended as best practice:
Examples of these files are available in the [Template Repository](https://github.com/canada-ca/template-gabarit).
-## Publishing a Legacy Application
+## 7. Publishing a Legacy Application
Publishing a legacy application can seem like a lot of work but it is feasible and actually a good investment if the application will continue to be used in the future.
Documentation could be improved during the release project to help increase community contributions.
@@ -237,7 +237,7 @@ One way of limiting those risks is to not provide the configurations of the prod
Scanning tools with advanced functionalities and security tests should be considered to help the development teams speed up the review and clean up process.
-## Work in the Open
+## 8. Work in the Open
### Release Early, Release Often
diff --git a/en/guides/using-open-source-software.md b/en/guides/using-open-source-software.md
index 355c215..504c07d 100644
--- a/en/guides/using-open-source-software.md
+++ b/en/guides/using-open-source-software.md
@@ -6,14 +6,14 @@ These align with the [Digital Standards](https://www.canada.ca/en/government/pub
The steps for GC to use open source software are:
-1. [Actively and Fairly Consider Open Source Software](#actively-and-fairly-consider-open-source-software)
-2. [Verify Open Source Software Ownership or Licence](#verify-open-source-software-ownership-or-licence)
-3. [Evaluate Support Options](#evaluate-support-options)
-4. [Use Open Source Software Without Modification](#use-open-source-software-without-modification)
-5. [Use Open Source Software With Modifications](#use-open-source-software-with-modifications)
-6. [Register to Open Resource Exchange](#register-to-open-resource-exchange)
+1. [Actively and Fairly Consider Open Source Software](#1-actively-and-fairly-consider-open-source-software)
+2. [Verify Open Source Software Ownership or Licence](#2-verify-open-source-software-ownership-or-licence)
+3. [Evaluate Support Options](#3-evaluate-support-options)
+4. [Use Open Source Software Without Modification](#4-use-open-source-software-without-modification)
+5. [Use Open Source Software With Modifications](#5-use-open-source-software-with-modifications)
+6. [Register to Open Resource Exchange](#6-register-to-open-resource-exchange)
-## Actively and Fairly Consider Open Source Software
+## 1. Actively and Fairly Consider Open Source Software
Be aware that open source software is not completely free, so take into account the total cost of ownership (TCO) of migrating, including exit, transition, and support costs.
@@ -61,7 +61,7 @@ The quality of the code and the typical response time for patching security-rela
As per any software, you should maintain best practices and have a process in place to list all packages in use as well as their version in order to patch them promptly.
-## Verify Open Source Software Ownership or Licence
+## 2. Verify Open Source Software Ownership or Licence
Whenever the Crown is contemplating acquiring software under an open source licence, departments should review the terms and conditions to validate if they can accept and comply with them given their particular business context.
@@ -103,7 +103,7 @@ The following are lists of licences categorized by permissive and reciprocal. Fo
* Mozilla Public License (MPL)
* Open Software License (OSL)
-## Evaluate Support Options
+## 3. Evaluate Support Options
Use of open source software introduces a different model based on support services rather than obtaining software licences.
@@ -132,7 +132,7 @@ Another scenario that may become recurrent would be choosing an open source soft
When custom development requires the use of contracted developers, ensure that the proper rights to the source code are obtained to release as open source in accordance with the [Guide for Publishing Open Source Code][guide-publish-oss].
-## Use Open Source Software Without Modification
+## 4. Use Open Source Software Without Modification
> **Using open source software without modification does not require that code be shared back.**
@@ -157,7 +157,7 @@ Custom development using open source software programming languages and dependen
For development or when writing source code, see [Guide for Publishing Open Source Code][guide-publish-oss].
-## Use Open Source Software With Modifications
+## 5. Use Open Source Software With Modifications
> **Using open source software with modifications is not generally considered distribution and does not require that code be shared back.**
@@ -177,8 +177,7 @@ It's easy to copy (fork) open source software and start making changes to the so
If a literal fork is created, which means taking a copy of the source code and maintaining your own version independently from the original project, be aware it can make future updates and security patches hard to implement.
The development team that made the changes will be responsible for maintaining those changes indefinitely unless they are contributed to the upstream version, which is the original project from which the source code was taken.
-To make changes to open source software, engage with the community and submit changes upstream to ensure that they are supported by future updates.
-See [Guide for Contributing to Open Source Software][guide-contribute-oss].
+To make changes to open source software, engage with the community and submit changes upstream to ensure that they are supported by future updates, see the [Guide for Contributing to Open Source Software][guide-contribute-oss].
Note: the term "fork" in the literal sense may be confused with the process of forking (cloning) projects on GitHub, GitLab and Bitbucket, which is critical to submit changes back to the original project.
@@ -195,7 +194,7 @@ The [Open Source Initiative approved licenses](https://opensource.org/licenses/a
* European Union Public License (EUPL)
* Open Software License (OSL)
-## Register to Open Resource Exchange
+## 6. Register to Open Resource Exchange
Departments are encouraged to add all open source software your department or agency is using to the [Open Source Software section on the Open Resource Exchange](https://canada-ca.github.io/ore-ero/en/index.html).
diff --git a/fr/guides/acquerir-logiciels-libres.md b/fr/guides/acquerir-logiciels-libres.md
deleted file mode 100644
index 4f8f6b0..0000000
--- a/fr/guides/acquerir-logiciels-libres.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# Acquérir des logiciels libres
-
-La Directive sur la gestion des technologies de l’information, annexe C, fournit les procédures obligatoires pour l’évaluation de l’architecture intégrée, qui seront utilisées par les Conseils d’examen de l’architecture (CEA) et le CEA intégré du gouvernement du Canada (GC) en tant que cadre d’évaluation pour examiner les initiatives numériques visant à assurer que le GC agit comme unique entreprise et à assurer l’harmonisation ministérielle avec l’orientation numérique du GC.
-
-Celles-ci s’harmonisent avec les Normes numériques et l’exigence C.2.3.8 des Procédures obligatoires pour l’évaluation de l’architecture intégrée qui prévoient que, dans la mesure du possible, des logiciels libres soient utilisés en premier.
-
-Les lois et la politique applicables au GC peuvent exiger que l’acquisition de logiciels, de services d’entretien de logiciels ou de services professionnels liés aux logiciels fasse l’objet d’une concurrence par une invitation à soumissionner destinée aux fournisseurs pour l’appel d’offres des biens ou services. Toutefois, lorsque des logiciels peuvent être obtenus gratuitement et seuls, sans frais obligatoires pour les manuels, les médias ou les services, et que le besoin opérationnel justifie l’acquisition de logiciels libres au lieu de logiciels propriétaires, l’acquisition de tels logiciels par téléchargement ou autrement sans appel d’offres peut être possible.
-Dans le cas où le logiciel libre a déjà été acquis, ou n’est pas lié par les lois sur les contrats commerciaux, passez à la section « Utiliser des logiciels libres ».
-
-## Principes d’acquisition
-
-Si le Canada n’a pas déjà acquis le logiciel libre, puisqu’il se peut que la loi exige que l’acquisition fasse l’objet d’une concurrence, le GC doit justifier, par l’entremise de son cas conceptuel et de l’élaboration de son besoin opérationnel, une raison opérationnelle de bonne foi d’acquérir le logiciel libre au lieu d’un logiciel propriétaire, lorsque le logiciel libre est choisi. Cette même justification est requise pour tout logiciel propriétaire.
-
-Par conséquent, avant l’acquisition, on doit consulter l’unité des services juridiques de votre institution afin d’examiner les besoins opérationnels du logiciel et bien préciser dans tout avis d’appel d’offres les modalités du contrat qui s’appliqueraient à votre acquisition.
-
-La présente orientation stratégique sur les logiciels libres ne supprime ni n’annule aucune autre orientation stratégique du gouvernement du Canada, comme la Directive sur la gestion de l’approvisionnement et l’orientation connexe. Lorsque le Canada acquiert des logiciels libres, l’autorité contractante doit d’abord demander au Conseil du Trésor ou à d’autres autorités compétentes des exemptions appropriées si le contrat qui en résulte contient des modalités qui ne sont pas conformes aux politiques actuelles du gouvernement du Canada.
diff --git a/fr/guides/acquisition-logiciels-libres.md b/fr/guides/acquisition-logiciels-libres.md
new file mode 100644
index 0000000..ed8e6c4
--- /dev/null
+++ b/fr/guides/acquisition-logiciels-libres.md
@@ -0,0 +1,18 @@
+# Acquérir des logiciels libres
+
+La [Directive sur la gestion des technologies de l’information, Annexe C](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249§ion=procedure&p=C#appC), fournit les procédures obligatoires pour l’évaluation de l’architecture intégrée, qui seront utilisées par les Conseils d’examen de l’architecture (CEA) et le CEA intégré du gouvernement du Canada (GC) en tant que cadre d’évaluation pour examiner les initiatives numériques visant à assurer que le GC agit comme unique entreprise et à assurer l’harmonisation ministérielle avec l’orientation numérique du GC.
+
+Celles-ci s’harmonisent avec les [Normes numériques](https://www.canada.ca/fr/gouvernement/systeme/gouvernement-numerique/normes-numeriques-gouvernement-canada.html) et [l’exigence C.2.3.8 des Procédures obligatoires pour l’évaluation de l’architecture intégrée](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#claC.2.3.8) qui prévoient que, dans la mesure du possible, des logiciels libres soient utilisés en premier.
+
+Les lois et la politique applicables au GC peuvent exiger que l’acquisition de logiciels, de services d’entretien de logiciels ou de services professionnels liés aux logiciels fasse l’objet d’une concurrence par une invitation à soumissionner destinée aux fournisseurs pour l’appel d’offres des biens ou services.
+Toutefois, lorsque des logiciels peuvent être obtenus gratuitement et seuls, sans frais obligatoires pour les manuels, les médias ou les services, et que le besoin opérationnel justifie l’acquisition de logiciels libres au lieu de logiciels propriétaires, l’acquisition de tels logiciels par téléchargement ou autrement sans appel d’offres peut être possible.
+Dans le cas où le logiciel libre a déjà été acquis, ou n’est pas lié par les lois sur les contrats commerciaux, passez à la section « Utiliser des logiciels libres ».
+
+## Principes d’acquisition
+
+Si le Canada n’a pas déjà acquis le logiciel libre, puisqu’il se peut que la loi exige que l’acquisition fasse l’objet d’une concurrence, le GC doit justifier, par l’entremise de son cas conceptuel et de l’élaboration de son besoin opérationnel, une raison opérationnelle de bonne foi d’acquérir le logiciel libre au lieu d’un logiciel propriétaire, lorsque le logiciel libre est choisi. Cette même justification est requise pour tout logiciel propriétaire.
+
+Par conséquent, avant l’acquisition, vous devez consulter l’unité des services juridiques de votre institution afin d’examiner les besoins opérationnels du logiciel et bien préciser dans tout avis d’appel d’offres les modalités du contrat qui s’appliqueraient à votre acquisition.
+
+La présente orientation stratégique sur les logiciels libres ne supprime ni n’annule aucune autre orientation stratégique du gouvernement du Canada, comme la Directive sur la gestion de l’approvisionnement et l’orientation connexe.
+Lorsque le Canada acquiert des logiciels libres, l’autorité contractante doit d’abord demander au Conseil du Trésor ou à d’autres autorités compétentes des exemptions appropriées si le contrat qui en résulte contient des modalités qui ne sont pas conformes aux politiques actuelles du gouvernement du Canada.
diff --git a/fr/guides/cas-conceptuel-pour-logiciels-libres.md b/fr/guides/cas-conceptuel-pour-logiciels-libres.md
deleted file mode 100644
index 0865cf5..0000000
--- a/fr/guides/cas-conceptuel-pour-logiciels-libres.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Élaborer un cas conceptuel pour Open Source
-
-Avant toute forme de développement ou d’acquisition, les propriétaires fonctionnels devraient définir à la fois un cas conceptuel et une exigence opérationnelle pour tout projet numérique.
-
-Un cas conceptuel détermine les renseignements clés sur lesquels un projet numérique possible doit être fondé, et doit être achevé avant que l’exigence opérationnelle ne soit établie.
-
-Une exigence opérationnelle est différente des exigences fonctionnelles, et plus grandes, ou des exigences techniques d’un projet numérique seulement. Une exigence fonctionnelle définit une fonction particulière du logiciel afin d’obtenir un résultat et répond à une exigence opérationnelle plus précise. Une exigence technique définit une capacité ou les attributs nécessaires pour travailler avec d’autres logiciels, et exprime la décision architecturale plus vaste d’appuyer le projet.
-
-L’exigence opérationnelle comprend l’examen des exigences fonctionnelles et techniques, mais aussi d’autres éléments généraux, afin de répondre à la nature, à l’objectif et aux besoins du projet numérique à un niveau élevé. Par conséquent, l’exigence opérationnelle dictera la voie à suivre pour l’acquisition et le développement de logiciels, et les exigences techniques et fonctionnelles ne peuvent être utilisées seules comme justification aux fins d’une évaluation des avantages des logiciels libres ou des logiciels propriétaires.
-
-L’annexe C de la [Politique sur la planification et la gestion des investissements](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=32593) prévoit des procédures obligatoires pour les cas conceptuels pour les projets numériques. Même si la directive ne s’applique qu’aux projets dépassant un certain seuil, il est important de noter que la grande majorité des cadres de gestion de projets agiles commencent par un artefact qui correspond à un cas conceptuel comme une vision de projet ou des objectifs de projet.
-
-## Évaluer les exigences
-
-Les exigences techniques et fonctionnelles ne peuvent être utilisées comme justification aux fins d’évaluation des logiciels libres et des logiciels propriétaires, uniquement pour les exigences opérationnelles.
-Voici des exemples d’éléments qui peuvent être pris en compte dans la création d’exigences opérationnelles, mais il est important de se rappeler que les règles d’approvisionnement peuvent requérir que les exigences opérationnelles permettent l’offre de logiciels propriétaires et de logiciels libres.
-
-### Utilisation des normes internationales ou canadiennes
-
-Les exigences opérationnelles peuvent requérir que la demande sous-jacente soit conforme aux normes internationales ou canadiennes, par exemple, sans toutefois s’y limiter, l’exigence selon laquelle les langues officielles exigeant que le logiciel soit disponible dans les deux langues officielles.
-
-### Flexibilité de la licence
-
-Les licences de logiciels libres peuvent offrir plus de flexibilité qu’une licence propriétaire pour les produits livrables d’un projet numérique.
-Si l’exigence opérationnel profiterait de la réutilisation du logiciel, le GC peut acquérir un logiciel afin de pourvoir l’utiliser dans des projets ultérieurs au GC. Un titulaire de licence de logiciel propriétaire peut accorder ce droit de réutilisation sur demande, mais par sa nature, tous les logiciels libres sont réutilisables et donc conformes à cette demande par défaut.
-
-### Possibilité d’utiliser à n’importe quel usage
-
-Les exigences opérationnelles peuvent être définies de telle sorte que le logiciel puisse être utilisé à n’importe quel usage, sans aucune restriction, ou permettre à d’autres utilisateurs d’utiliser le logiciel. Les conditions du logiciel libre sont plus susceptibles de respecter cette exigence.
-
-### Capacité d’évaluer le code
-
-Le GC peut fixer ses exigences de sorte que le code source soit disponible aux fins d’audit par un tiers afin de déterminer la qualité, la fonctionnalité et la sécurité du logiciel.
-
-### Harmonisation avec le Gouvernement ouvert
-
-En outre, le GC peut fixer ses exigences de sorte que le code source soit fourni au public afin de permettre une plus grande transparence et de s’harmoniser avec les [principes du gouvernement ouvert dans la charte du D9](https://www.canada.ca/fr/gouvernement/systeme/gouvernement-numerique/ameliorer-services-numeriques/chartedigital9.html).
-
-### Possibilité de distribuer le logiciel
-
-On peut établir des exigences opérationnelles de telle sorte que le logiciel puisse être distribué à n’importe qui, par choix, afin de s’assurer que les autres institutions de la Couronne n’ont pas besoin de devenir des clients du fournisseur initial pour accéder aux services fournis par un autre organisme et les utiliser. Par exemple, la Couronne fédérale pourrait souhaiter pouvoir fournir le logiciel sans frais supplémentaires aux institutions provinciales ou municipales.
diff --git a/fr/guides/contribution-logiciels-libres.md b/fr/guides/contribution-logiciels-libres.md
new file mode 100644
index 0000000..ca00bf0
--- /dev/null
+++ b/fr/guides/contribution-logiciels-libres.md
@@ -0,0 +1,107 @@
+# Guide de contribution aux logiciels libres (ébauche)
+
+La [Directive sur la gestion des technologies de l’information, Annexe C](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249§ion=procedure&p=C#appC), fournit les procédures obligatoires pour l’évaluation de l’architecture intégrée.
+Celles-ci seront utilisées par le Comité d’examen de l’architecture ministérielle et le Comité d’examen de l’architecture intégrée du GC en tant que cadre d’évaluation pour les initiatives numériques pour assurer que tous les sous-organismes du GC adhèrent à une seule direction numérique cohérente.
+
+Cette stratégie s’harmonise avec les [Normes numériques](https://www.canada.ca/fr/gouvernement/systeme/gouvernement-numerique/normes-numeriques-gouvernement-canada.html) et [l’exigence C.2.3.8 des Procédures obligatoires pour l’évaluation de l’architecture intégrée](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#claC.2.3.8), qui prévoient que tous les codes sources personnalisés doivent être publiés sous une licence libre appropriée.
+
+À ce titre, il est recommandé, pour les ministères, de contribuer à la communauté toute modification au code source apportée au logiciel libre tiers, que ce soit à l’interne par les employés du GC ou par l’intermédiaire de contrats d’approvisionnement.
+
+## Il y a de nombreuses façons de contribuer
+
+Les communautés de logiciels libres sont menées par une vaste gamme de contributions.
+Du code qui règle les bogues ou met en place des fonctionnalités de valeur est évidemment très important, mais des contributions qui ne sont pas du code, comme rédiger ou modifier les documents, ou présenter des demandes de fonctionnalités et des rapports de bogues, sont également très appréciées.
+Même simplement appuyer la contribution des autres ou exprimer un intérêt à la demande de fonctionnalité d’un autre, peut être une précieuse contribution.
+
+Les étapes à suivre pour que le GC contribue du code dans les communautés de logiciels libres sont les suivantes :
+
+1. [Vérifier la licence des logiciels libres](#1-vérifier-la-licence-des-logiciels-libres)
+2. [Vérifier les processus et politiques de contribution](#2-vérifier-les-processus-et-politiques-de-contribution)
+3. [Approbations supplémentaires](#3-approbations-supplémentaires)
+4. [Contribuer au projet](#4-contribuer-au-projet)
+5. [Contribuer par l’intermédiaire des services professionnels](#5-contribuer-par-lintermédiaire-des-services-professionnels)
+6. [Publier les contributions indépendamment de l’acceptation en amont](#6-publier-les-contributions-indépendamment-de-lacceptation-en-amont)
+
+## 1. Vérifier la licence des logiciels libres
+
+Le GC peut contribuer à tous les logiciels ayant une [licence approuvée par la Open Source Initiative](https://opensource.org/licenses) ou la [Free Software Foundation](https://www.gnu.org/licenses/license-list.html).
+
+Si une licence pour un logiciel développé ouvertement est sous une autre licence, il faut consulter un conseiller juridique afin de préciser si les contributions sont recommandées.
+
+## 2. Vérifier les processus et politiques de contribution
+
+Certains projets peuvent avoir des politiques précises pour la contribution de code (accord de licence des contributeurs, certificat d’origine du développeur) de même que des processus (modèles, plateformes, etc.).
+Avant de présenter une contribution, les employés devraient bien comprendre les processus et les politiques de contribution au projet.
+Les employés devraient ensuite veiller à ce que les approbations déléguées répondent à ces exigences.
+
+### Accord de licence des contributeurs
+
+Les accords de licence des contributeurs (ALC) sont des contrats que certains responsables de projet exigent que les contributeurs externes signent avant d’accepter leurs contributions.
+Ces contrats pourraient contenir diverses clauses, y compris les exemples suivants :
+
+- Le contributeur externe confirme que le travail d’origine (la contribution) est son propre travail et peut donc légalement le partager avec le projet.
+- Le droit d’auteur de la contribution doit être transféré aux responsables du projet.
+- Les droits de brevets sont accordés aux responsables du projet pour les besoins de ce projet.
+- Autres
+
+Les contrats pouvant être complexes et contenir de nombreuses clauses différentes, il est vivement recommandé de consulter un avocat avant d’accepter ces obligations contractuelles supplémentaires.
+
+En général, ce n’est pas un problème de contribuer à un projet qui a un ALC en place, mais une analyse supplémentaire est une pratique exemplaire.
+Certains projets s’éloignent de ces contrats complexes pour éliminer l’obstacle qu’ils créent autour des contributions externes en faveur du certificat d’origine du développeur.
+
+### Certificat d’origine du développeur
+
+Un certificat d’origine du développeur (COD) est considéré comme une façon de dire aux responsables du projet qu’en présentant cette contribution le contributeur confirme qu’il a le droit de le faire.
+
+Il s’agit habituellement d’ajouter « signé par : contributeur@courriel.com » dans la présentation du code.
+
+Contrairement au ALC, si vous avez le droit de présenter une contribution, un COD ne devrait pas poser de problème comme vous devriez déjà avoir obtenu les approbations appropriées pour contribuer au projet.
+Voir [Approbations supplémentaires](#3-approbations-supplémentaires).
+
+## 3. Approbations supplémentaires
+
+Si, pour une raison ou une autre, les approbations ministérielles déléguées ne respectent pas les exigences de contribution tierce, les employés devraient contacter leur superviseur pour savoir comment obtenir les approbations supplémentaires requises.
+Les ministères devraient définir des critères spécifiques pour l’approbation de contributions aux logiciels libres et les décrire clairement aux employés.
+
+### Temps
+
+Certains ministères peuvent instituer des directives ou des politiques énonçant que les employés doivent obtenir l’accord de leur gestionnaire pour passer du temps public à contribuer aux logiciels libres.
+Cela ne devrait pas être destiné à réduire la contribution aux logiciels libres, mais seulement de permettre la priorisation des besoins opérationnels; la politique par défaut devrait être d’encourager la contribution aux projets libres utilisés par le GC.
+
+### Ministère
+
+Semblable aux données ouvertes ou aux renseignements ouverts visés par la [Directive sur le gouvernement ouvert](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=28108), la publication du code source sous une licence libre exige les approbations du bon ministère ou organisme.
+Cette personne peut varier en fonction du ministère et la délégation devrait être encouragée au niveau le plus bas possible pour encourager la contribution aux projets de logiciels libres tiers.
+
+## 4. Contribuer au projet
+
+### S’identifier en tant qu’employé du gouvernement du Canada
+
+En vue de contribuer, il peut être nécessaire d’établir un compte avec le site ou la plateforme où le projet auquel vous voulez contribuer est hébergé.
+Cela devrait indiquer clairement que vous êtes un employé du gouvernement du Canada puisque vous contribueriez en tant que tel.
+S’il y a une option de voir votre organisme listé sur le projet, il serait avantageux de le faire.
+
+À l’heure actuelle, il est recommandé que les employés utilisent leur nom au complet et l’adresse courriel du gouvernement du Canada pour toutes les contributions de code aux dépôts publics tout en agissant dans l’exercice de leurs fonctions ou de leur emploi comme il s’agit du principal moyen d’identifier leur travail.
+Certains services vous permettent d’énumérer plusieurs adresses courriel, d’autres peuvent vous demander de créer un nouveau compte pour les contributions officielles.
+
+**Remarque** : cette disposition est liée à la [Loi sur les inventions des fonctionnaires, article 3](https://laws-lois.justice.gc.ca/fra/lois/P-32/TexteComplet.html#h-3).
+Des éclaircissements supplémentaires sur les moyens de s’identifier en tant qu’employé du GC sans exiger l’adresse de courriel dans les engagements devront être recherchés pour faciliter le processus et votre organisme peut déjà disposer de ses propres directives sur ce sujet.
+
+### Présenter les changements
+
+Pour apporter des changements dans les logiciels libres, collaborez avec la communauté et présentez vos changements en amont, ce qui signifie au projet d’origine, afin d’assurer que vos modifications sont appuyées par les futures mises à jour.
+De cette façon, vos changements aideront à améliorer le logiciel pour tous ceux qui l’utilisent, mais vous veillerez également à rester conforme avec le projet d’origine et à ne pas avoir à conserver une version distincte du code source.
+
+Contribuer à un tiers devrait être fait conformément au modèle de gouvernance du projet, si un tel modèle est présent.
+
+## 5. Contribuer par l’intermédiaire des services professionnels
+
+Si votre ministère aimerait tirer parti des services professionnels pour contribuer à des projets tiers, consultez [Obtenir les droits de personnaliser le code dans les contrats](publication-code-source-libre.md#2-obtenir-les-droits-de-personnaliser-le-code-dans-les-contrats).
+
+## 6. Publier les contributions indépendamment de l’acceptation en amont
+
+Qu’un ensemble de changements soit accepté ou non en amont en tant que contribution, les changements doivent quand même être publiés conformément au [Guide de publication de code source libre](publication-code-source-libre.md).
+
+La publication permet en amont, dans le projet d’origine, de tenir compte des changements ultérieurement et permet à des tiers de tenir compte des changements, indépendamment du moment où le projet d’origine le fait ou s’il le fait.
+
+Les changements non acceptés par le projet d’origine devraient tout de même être notés dans les forums du projet d’origine lorsque cela est possible et approprié, pour que les tiers qui pourraient être intéressés par ces changements aient un moyen de les découvrir.
diff --git "a/fr/guides/contribution-\303\240-des-logiciels-libres.md" "b/fr/guides/contribution-\303\240-des-logiciels-libres.md"
deleted file mode 100644
index e33fed2..0000000
--- "a/fr/guides/contribution-\303\240-des-logiciels-libres.md"
+++ /dev/null
@@ -1,92 +0,0 @@
-# Guide de contribution aux logiciels libres
-
-La [Directive sur la gestion des technologies de l’information](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249§ion=procedure&p=C#appC), Annexe C, fournit les procédures obligatoires pour l’évaluation de l’architecture intégrée. Celles-ci seront utilisées par le Comité d’examen de l’architecture ministérielle et le Comité d’examen de l’architecture intégrée du GC en tant que cadre d’évaluation pour les initiatives numériques pour assurer que tous les sous-organismes du GC adhèrent à une seule direction numérique cohérente.
-
-Cette stratégie s’harmonise avec les [Normes numériques](https://www.canada.ca/fr/gouvernement/systeme/gouvernement-numerique/normes-numeriques-gouvernement-canada.html) et l’exigence C.2.3.8 des [Procédures obligatoires pour l’évaluation de l’architecture intégrée](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#claC.2.3.8), qui prévoient que tous les codes sources personnalisés doivent être publiés sous une licence de logiciel libre appropriée.
-
-À ce titre, il est recommandé, pour les ministères, de contribuer à la collectivité toute modification au code source apportée au logiciel libre tiers, que ce soit à l’interne par les employés du GC ou par l’intermédiaire de contrats d’approvisionnement.
-
-## Il y a de nombreuses façons de contribuer
-
-Les collectivités de sources ouvertes sont menées par une vaste gamme de contributions. Un code qui fixe les bogues ou met en place des fonctionnalités de valeur est évidemment très important, mais des contributions qui ne sont pas un code, comme rédiger ou modifier les documents, ou présenter des demandes de fonctionnalités et des rapports de bogues, sont également très appréciées. Même simplement appuyer la contribution des autres ou exprimer un intérêt à la demande de fonctionnalité d’un autre, peut être une précieuse contribution.
-
-Les étapes à suivre pour que le GC contribue un code dans les collectivités de logiciels libres sont les suivantes :
-
-1. [Vérifier la licence des logiciels libres](#vérifier-la-licence-des-logiciels-libres)
-2. [Vérifier les processus et politiques de contribution](#vérifier-les-processus-et-politiques-de-contribution)
-3. [Approbations supplémentaires](#approbations-supplémentaires)
-4. [Contribuer au projet](#contribuer-au-projet)
-5. [Contribuer par l’intermédiaire des services professionnels](#contribuer-par-l’intermédiaire-des-services-professionnels)
-6. [Publier les contributions indépendamment de l’acceptation en amont](#publier-les-contributions-indépendamment-de-l’acceptation-en-amont)
-
-## Vérifier la licence des logiciels libres
-
-Le GC peut contribuer à tous les logiciels ayant une [licence approuvée par Open Source Initiative](https://opensource.org/licenses) ou une [licence de logiciels gratuits de Free Software Foundation](https://www.gnu.org/licenses/license-list.html).
-
-Si une licence pour un logiciel développé ouvertement est sous une autre licence, il faut consulter un conseiller juridique afin de préciser si les contributions sont recommandées.
-
-## Vérifier les processus et politiques de contribution
-
-Certains projets peuvent avoir des politiques précises pour la contribution de code (accord de licence des contributeurs, certificat d’origine du développeur) de même que des processus (modèles, plateformes, etc.). Avant de présenter une contribution, les employés devraient bien comprendre les processus et les politiques de contribution au projet. Les employés devraient ensuite veiller à ce que les approbations déléguées répondent à ces exigences.
-
-### Accord de licence des contributeurs
-
-Les accords de licence des contributeurs (ALC) sont des contrats que certains responsables de projet exigent que les contributeurs externes signent avant d’accepter leurs contributions. Ces contrats pourraient contenir diverses clauses, y compris les exemples suivants :
-
-* Le contributeur externe confirme que le travail d’origine (la contribution) est son propre travail et peut donc légalement le partager avec le projet.
-* Le droit d’auteur de la contribution doit être transféré aux responsables du projet.
-* Les droits de brevets sont accordés aux responsables du projet pour les besoins de ce projet.
-* Autres
-
-Les contrats pouvant être complexes et contenir de nombreuses clauses différentes, il est vivement recommandé de consulter un avocat avant d’accepter ces obligations contractuelles supplémentaires.
-
-En général, ce n’est pas un problème de contribuer à un projet qui a un ALC en place, mais une analyse supplémentaire est une pratique exemplaire. Certains projets s’éloignent de ces contrats complexes pour éliminer l’obstacle qu’ils créent autour des contributions externes en faveur du certificat d’origine du développeur.
-
-### Certificat d’origine du développeur
-
-Un certificat d’origine du développeur (COD) est considéré comme une façon de dire aux responsables du projet qu’en présentant cette contribution le contributeur confirme qu’il a le droit de le faire.
-
-Il s’agit habituellement d’ajouter « signé par : contributor@email.com » dans la présentation du code.
-
-Contrairement au ALC, si vous avez le droit de présenter une contribution, un COD ne devrait pas poser de problème comme vous devriez déjà avoir obtenu les approbations appropriées pour contribuer au projet. Voir [Approbations supplémentaires](#approbations-supplémentaires).
-
-## Approbations supplémentaires
-
-Si, pour une raison ou une autre, les approbations ministérielles déléguées ne respectent pas les exigences de contribution tierce, les employés devraient contacter leur superviseur pour savoir comment obtenir les approbations supplémentaires requises. Les ministères devraient définir des critères spécifiques pour l’approbation de contributions à source ouverte et les décrire clairement aux employés.
-
-### Temps
-
-Certains ministères peuvent instituer des directives ou des politiques énonçant que les employés doivent obtenir l’accord de leur gestionnaire pour passer du temps public à contribuer aux logiciels libres. Cela ne devrait pas être destiné à réduire la contribution à source ouverte, mais seulement de permettre la priorisation des besoins opérationnels; la politique par défaut devrait être d’encourager la contribution aux projets à source ouverte utilisés par le GC.
-
-### Ministère
-
-Semblable aux données ouvertes ou aux renseignements ouverts visés par la [Directive sur le gouvernement ouvert](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=28108), la publication du code source sous une licence de logiciel libre exige les approbations du bon ministère ou organisme.
-Cette personne peut varier en fonction du ministère et la délégation devrait être encouragée au niveau le plus bas possible pour encourager la contribution aux projets de logiciels libres tiers.
-
-## Contribuer au projet
-
-### S’identifier en tant qu’employé du gouvernement du Canada
-
-En vue de contribuer, il peut être nécessaire d’établir un compte avec le site ou la plateforme où le projet auquel vous voulez contribuer est hébergé. Cela devrait indiquer clairement que vous êtes un employé du gouvernement du Canada puisque vous contribueriez en tant que tel. S’il y a une option de voir votre organisme listé sur le projet, il serait avantageux de le faire.
-
-À l’heure actuelle, il est recommandé que les employés utilisent leur nom au complet et l’adresse courriel du gouvernement du Canada pour toutes les contributions de code aux dépôts publics tout en agissant dans l’exercice de leurs fonctions ou de leur emploi comme il s’agit du principal moyen d’identifier leur travail. Certains services vous permettent d’énumérer plusieurs adresses courriel, d’autres peuvent vous demander de créer un nouveau compte pour les contributions officielles.
-
-**Remarque** : cette disposition est liée à la [Loi sur les inventions des fonctionnaires](https://laws-lois.justice.gc.ca/fra/lois/P-32/TexteComplet.html#h-3), article 3. Des éclaircissements supplémentaires sur les moyens de s’identifier en tant qu’employé du GC sans exiger l’adresse de courriel dans les engagements devront être recherchés pour faciliter le processus et votre organisme peut déjà disposer de ses propres directives sur ce sujet.
-
-### Présenter les changements
-
-Pour apporter des changements dans les logiciels libres, collaborez avec la collectivité et présentez vos changements en amont, ce qui signifie au projet d’origine, afin d’assurer que vos modifications sont appuyées par les futures mises à jour. De cette façon, vos changements aideront à améliorer le logiciel pour tous ceux qui l’utilisent, mais vous veillerez également à rester conforme avec le projet d’origine et à ne pas avoir à conserver une version distincte du code source.
-
-Contribuer à un tiers devrait être fait conformément au modèle de gouvernance du projet, si un tel modèle est présent.
-
-## Contribuer par l’intermédiaire des services professionnels
-
-Si votre ministère aimerait tirer parti des services professionnels pour contribuer à des projets tiers, consultez [Obtenir les droits de personnaliser le code dans les contrats](publication-code-source-ouvert.md#obtenir-les-droits-de-personnaliser-le-code-dans-les-contrats).
-
-## Publier les contributions indépendamment de l’acceptation en amont
-
-Qu’un ensemble de changements soit accepté ou non en amont en tant que contribution, les changements doivent quand même être publiés conformément au [Guide pour la publication de code source libre](publication-code-source-ouvert.md).
-
-La publication permet en amont, dans le projet d’origine, de tenir compte des changements ultérieurement et permet à des tiers de tenir compte des changements, indépendamment du moment où le projet d’origine le fait ou s’il le fait.
-
-Les changements non acceptés par le projet d’origine devraient tout de même être notés dans les forums du projet d’origine lorsque cela est possible et approprié, pour que les tiers qui pourraient être intéressés par ces changements aient un moyen de les découvrir.
diff --git a/fr/guides/definitions.md b/fr/guides/definitions.md
index 4392a2e..6842e00 100644
--- a/fr/guides/definitions.md
+++ b/fr/guides/definitions.md
@@ -2,7 +2,8 @@
## Définir, le cas échéant et dans la mesure du possible
-La Directive sur la gestion des technologies de l’information stipule, en vertu des points [C.2.3.8.1](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#appC) et [D2.2.1.4.2](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#appD), que « dans la mesure du possible », il faut privilégier des normes ouvertes et des logiciels libres. De même, les [Normes numériques](https://www.canada.ca/fr/gouvernement/systeme/gouvernement-numerique/normes-numeriques-gouvernement-canada.html) stipulent qu’il faut profiter des normes ouvertes et adopter des pratiques exemplaires, y compris l’utilisation de logiciels libres, s’il y a lieu.
+La Directive sur la gestion des technologies de l’information stipule, en vertu des points [C.2.3.8.1](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#appC) et [D2.2.1.4.2](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#appD), que « dans la mesure du possible », il faut privilégier des normes ouvertes et des logiciels libres.
+De même, les [Normes numériques](https://www.canada.ca/fr/gouvernement/systeme/gouvernement-numerique/normes-numeriques-gouvernement-canada.html) stipulent qu’il faut profiter des normes ouvertes et adopter des pratiques exemplaires, y compris l’utilisation de logiciels libres, s’il y a lieu.
Le cas échéant et dans la mesure du possible sont définis comme tous les éléments qui ne sont pas exemptés en raison des suivants :
@@ -27,68 +28,99 @@ Pour que le code source puisse être considéré comme protégé, il doit conten
* certains types de renseignements détenus par la Société Radio Canada et Énergie atomique du Canada limitée;
* les renseignements confidentiels du Conseil privé de la Reine.
-Il est très peu probable que les développeurs incluent intentionnellement de tels renseignements dans leur code source. Par conséquent, le code source est considéré comme non classifié à moins que le développeur n’ait inclus, par inadvertance ou non, des renseignements qui relèvent des éléments énumérés ci-dessus.
+Il est très peu probable que les développeurs incluent intentionnellement de tels renseignements dans leur code source.
+Par conséquent, le code source est considéré comme non classifié à moins que le développeur n’ait inclus, par inadvertance ou non, des renseignements qui relèvent des éléments énumérés ci-dessus.
-Dans la mesure du possible, cette information devrait être retirée du code source afin d’accroître la capacité de partage du Code.
+Dans la mesure du possible, cette information devrait être retirée du code source afin d’accroître la capacité de partage du code.
## Termes
### Logiciel libre
-Le logiciel libre est généralement un logiciel dont le code de programmation sous-jacent est accessible aux utilisateurs pour la lecture, la modification et l’élaboration de nouvelles versions du logiciel intégrant des modifications. En particulier, le gouvernement du Canada (GC) considère que le logiciel libre est tout logiciel qui répond à toutes les exigences de base suivantes :
+Le logiciel libre est généralement un logiciel dont le code de programmation sous-jacent est accessible aux utilisateurs pour la lecture, la modification et l’élaboration de nouvelles versions du logiciel intégrant des modifications.
+En particulier, le gouvernement du Canada (GC) considère que le logiciel libre est tout logiciel qui répond à toutes les exigences de base suivantes :
1. Redistribution libre
-La licence n’interdit à aucune partie de vendre ou de distribuer le logiciel en tant qu’élément d’une distribution globale de logiciels contenant des programmes de plusieurs sources différentes. La licence n’exige pas de redevance ou d’autres frais pour cette vente.
+
+ La licence n’interdit à aucune partie de vendre ou de distribuer le logiciel en tant qu’élément d’une distribution globale de logiciels contenant des programmes de plusieurs sources différentes.
+ La licence n’exige pas de redevance ou d’autres frais pour cette vente.
2. Code source
-Le programme doit inclure le code source et permettre la distribution en code source ainsi que sous forme compilée. Lorsqu’une forme d’un produit n’est pas distribuée avec un code source, il doit y avoir un moyen bien connu d’obtenir le code source pour un coût de reproduction raisonnable, de préférence par téléchargement gratuit dans Internet. Le code source doit être la forme préférée dans laquelle un programmeur modifierait le programme. Le code source délibérément masqué n’est pas autorisé. Les formulaires intermédiaires comme la sortie d’un préprocesseur ou d’un traducteur ne sont pas autorisés.
+
+ Le programme doit inclure le code source et permettre la distribution en code source ainsi que sous forme compilée.
+ Lorsqu’une forme d’un produit n’est pas distribuée avec un code source, il doit y avoir un moyen bien connu d’obtenir le code source pour un coût de reproduction raisonnable, de préférence par téléchargement gratuit dans Internet.
+ Le code source doit être la forme préférée dans laquelle un programmeur modifierait le programme.
+ Le code source délibérément masqué n’est pas autorisé.
+ Les formulaires intermédiaires comme la sortie d’un préprocesseur ou d’un traducteur ne sont pas autorisés.
3. Travaux dérivés
-La licence doit autoriser les modifications et les travaux dérivés, et doit autoriser leur distribution dans les mêmes conditions que la licence du logiciel original.
+
+ La licence doit autoriser les modifications et les travaux dérivés, et doit autoriser leur distribution dans les mêmes conditions que la licence du logiciel original.
4. Intégrité du code source de l’auteur
-La licence ne peut restreindre la distribution du code source sous forme modifiée que si la licence autorise la distribution de « fichiers correctifs » avec le code source dans le but de modifier le programme au moment de la compilation. La licence doit expressément autoriser la distribution de logiciels élaborés à partir du code source modifié. La licence peut exiger que les travaux dérivés portent un nom ou un numéro de version différent du logiciel original.
+
+ La licence ne peut restreindre la distribution du code source sous forme modifiée que si la licence autorise la distribution de « fichiers correctifs » avec le code source dans le but de modifier le programme au moment de la compilation.
+ La licence doit expressément autoriser la distribution de logiciels élaborés à partir du code source modifié.
+ La licence peut exiger que les travaux dérivés portent un nom ou un numéro de version différent du logiciel original.
+
5. Aucune discrimination à l’égard des personnes ou des groupes
-La licence ne doit pas être discriminatoire à l’égard d’une personne ou d’un groupe de personnes.
+
+ La licence ne doit pas être discriminatoire à l’égard d’une personne ou d’un groupe de personnes.
6. Aucune discrimination à l’égard des domaines d’activité
-La licence ne doit pas empêcher quiconque d’utiliser le programme dans un domaine d’activité précis. Par exemple, il ne peut pas restreindre l’utilisation du programme dans une entreprise ni à des fins de recherche génétique.
+
+ La licence ne doit pas empêcher quiconque d’utiliser le programme dans un domaine d’activité précis.
+ Par exemple, il ne peut pas restreindre l’utilisation du programme dans une entreprise ni à des fins de recherche génétique.
7. Distribution de la licence
-Les droits liés au programme doivent s’appliquer à tous ceux à qui le programme est redistribué sans qu’il soit nécessaire d’obtenir une licence supplémentaire de la part de ces parties.
+
+ Les droits liés au programme doivent s’appliquer à tous ceux à qui le programme est redistribué sans qu’il soit nécessaire d’obtenir une licence supplémentaire de la part de ces parties.
8. La licence ne doit pas être spécifique à un produit
-Les droits liés au programme ne doivent pas dépendre du fait que le programme fait partie d’une distribution de logiciels particulière. Si le programme est extrait de cette distribution et utilisé ou distribué selon les conditions de la licence du programme, toutes les parties à qui le programme est redistribué devraient avoir les mêmes droits que ceux qui sont autorisés, conjointement à la distribution originale du logiciel.
+
+ Les droits liés au programme ne doivent pas dépendre du fait que le programme fait partie d’une distribution de logiciels particulière.
+ Si le programme est extrait de cette distribution et utilisé ou distribué selon les conditions de la licence du programme, toutes les parties à qui le programme est redistribué devraient avoir les mêmes droits que ceux qui sont autorisés, conjointement à la distribution originale du logiciel.
9. La licence ne doit pas restreindre d’autres logiciels
-La licence ne doit pas imposer de restrictions à d’autres logiciels distribués en même temps que le logiciel sous licence. Par exemple, la licence ne doit pas insister sur le fait que tous les autres programmes distribués sur le même support doivent être des logiciels libres.
+
+ La licence ne doit pas imposer de restrictions à d’autres logiciels distribués en même temps que le logiciel sous licence.
+ Par exemple, la licence ne doit pas insister sur le fait que tous les autres programmes distribués sur le même support doivent être des logiciels libres.
10. La licence doit être neutre sur le plan technologique
-Aucune disposition de la licence ne peut être fondée sur une technologie ou un style d’interface particulier.
+
+ Aucune disposition de la licence ne peut être fondée sur une technologie ou un style d’interface particulier.
### Propriétaire fonctionnel
-Le propriétaire fonctionnel est le cadre supérieur qui est chargé du secteur d’activité ou de programme pour lequel le projet numérique a été établi. Il revient au propriétaire fonctionnel de déterminer, dès le début d’un projet ou programme, les compétences requises, les résultats opérationnels attendus et les avantages, ainsi que de veiller à la réalisation des résultats opérationnels et des avantages une fois que le projet numérique est mis en œuvre.
+Le propriétaire fonctionnel est le cadre supérieur qui est chargé du secteur d’activité ou de programme pour lequel le projet numérique a été établi.
+Il revient au propriétaire fonctionnel de déterminer, dès le début d’un projet ou programme, les compétences requises, les résultats opérationnels attendus et les avantages, ainsi que de veiller à la réalisation des résultats opérationnels et des avantages une fois que le projet numérique est mis en œuvre.
### Exigence opérationnelle
-Une exigence opérationnelle est définie comme un besoin précis qui doit être pris en compte pour atteindre un objectif. Ce sont là les raisons pour lesquelles un projet définissant la nature et le but à un niveau élevé doit être réalisé. Dans le contexte des logiciels libres, cela signifie qu’il faut satisfaire à l’exigence du Canada d’avoir les droits d’utiliser le logiciel acquis à une fin particulière, comme la redistribution ou l’exécution de modifications au logiciel.
+Une exigence opérationnelle est définie comme un besoin précis qui doit être pris en compte pour atteindre un objectif.
+Ce sont là les raisons pour lesquelles un projet définissant la nature et le but à un niveau élevé doit être réalisé.
+Dans le contexte des logiciels libres, cela signifie qu’il faut satisfaire à l’exigence du Canada d’avoir les droits d’utiliser le logiciel acquis à une fin particulière, comme la redistribution ou l’exécution de modifications au logiciel.
### Cas conceptuel
-Un cas conceptuel désigne la création d’un cas pour un projet (anciennement appelé projets de TI) ou une initiative numérique conformément à l’annexe C de la Politique sur la planification et la gestion des investissements du Canada, avec la valeur du projet numérique figurant à l’annexe C.2.2 étant calculée de façon à inclure tous les investissements de projet pour les logiciels, l’entretien et les services professionnels associés à un projet numérique. Un cas concept est l’examen d’une occasion ou d’un problème opérationnel pour lequel un projet numérique peut être établi et comprend une description de l’état conceptuel futur et des résultats escomptés qui résulteront de l’investissement. Par conséquent, il doit tenir compte de tous les éléments du projet numérique chiffrés sur son cycle de vie.
+Un cas conceptuel désigne la création d’un cas pour un projet (anciennement appelé projets de TI) ou une initiative numérique conformément à l’annexe C de la Politique sur la planification et la gestion des investissements du Canada, avec la valeur du projet numérique figurant à l’annexe C.2.2 étant calculée de façon à inclure tous les investissements de projet pour les logiciels, l’entretien et les services professionnels associés à un projet numérique.
+Un cas concept est l’examen d’une occasion ou d’un problème opérationnel pour lequel un projet numérique peut être établi et comprend une description de l’état conceptuel futur et des résultats escomptés qui résulteront de l’investissement.
+Par conséquent, il doit tenir compte de tous les éléments du projet numérique chiffrés sur son cycle de vie.
### Exigence fonctionnelle
-Une exigence fonctionnelle est définie comme un besoin de travail plus précis qui doit être pris en compte pour atteindre un objectif. Ces éléments constituent le « quoi » pour un projet définissant les détails précis et décrivant une fonction particulière du logiciel ou d’une partie de celui-ci pour obtenir un résultat attendu.
+Une exigence fonctionnelle est définie comme un besoin de travail plus précis qui doit être pris en compte pour atteindre un objectif.
+Ces éléments constituent le « quoi » pour un projet définissant les détails précis et décrivant une fonction particulière du logiciel ou d’une partie de celui-ci pour obtenir un résultat attendu.
### Exigence technique
-Une exigence technique est définie comme une décision architecturale à l’appui d’un objectif. Ce sont là les éléments du « comment » pour un projet définissant l’architecture du logiciel et la manière dont il doit interagir avec d’autres systèmes et logiciels.
+Une exigence technique est définie comme une décision architecturale à l’appui d’un objectif.
+Ce sont là les éléments du « comment » pour un projet définissant l’architecture du logiciel et la manière dont il doit interagir avec d’autres systèmes et logiciels.
### Code source
-Un programme informatique dans sa langue de programmation originale, lisible par l’humain, avant d’être traduit en code objet, habituellement par un compilateur ou un interpréteur. Il est formé d’algorithmes et d’instructions informatiques et peut inclure des commentaires de la part du développeur.
+Un programme informatique dans sa langue de programmation originale, lisible par l’humain, avant d’être traduit en code objet, habituellement par un compilateur ou un interpréteur.
+Il est formé d’algorithmes et d’instructions informatiques et peut inclure des commentaires de la part du développeur.
### Logiciel propriétaire
diff --git a/fr/guides/importance-cas-conceptuel.md b/fr/guides/importance-cas-conceptuel.md
new file mode 100644
index 0000000..66adb31
--- /dev/null
+++ b/fr/guides/importance-cas-conceptuel.md
@@ -0,0 +1,52 @@
+# Élaborer un cas conceptuel un logiciel libre
+
+Avant toute forme de développement ou d’acquisition, les propriétaires fonctionnels devraient définir à la fois un cas conceptuel et une exigence opérationnelle pour tout projet numérique.
+
+Un cas conceptuel détermine les renseignements clés sur lesquels un projet numérique possible doit être fondé, et doit être achevé avant que l’exigence opérationnelle ne soit établie.
+
+Une exigence opérationnelle est différente des exigences fonctionnelles, et plus grandes, ou des exigences techniques d’un projet numérique seulement.
+Une exigence fonctionnelle définit une fonction particulière du logiciel afin d’obtenir un résultat et répond à une exigence opérationnelle plus précise.
+Une exigence technique définit une capacité ou les attributs nécessaires pour travailler avec d’autres logiciels, et exprime la décision architecturale plus vaste d’appuyer le projet.
+
+L’exigence opérationnelle comprend l’examen des exigences fonctionnelles et techniques, mais aussi d’autres éléments généraux, afin de répondre à la nature, à l’objectif et aux besoins du projet numérique à un niveau élevé.
+Par conséquent, l’exigence opérationnelle dictera la voie à suivre pour l’acquisition et le développement de logiciels, et les exigences techniques et fonctionnelles ne peuvent être utilisées seules comme justification aux fins d’une évaluation des avantages des logiciels libres ou des logiciels propriétaires.
+
+L’annexe C de la [Politique sur la planification et la gestion des investissements](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=32593) prévoit des procédures obligatoires pour les cas conceptuels pour les projets numériques.
+Même si la directive ne s’applique qu’aux projets dépassant un certain seuil, il est important de noter que la grande majorité des cadres de gestion de projets agiles commencent par un artefact qui correspond à un cas conceptuel comme une vision de projet ou des objectifs de projet.
+
+
+ Évaluer les exigences
+
+Évaluer les exigences
+
+Les exigences techniques et fonctionnelles ne peuvent être utilisées comme justification aux fins d’évaluation des logiciels libres et des logiciels propriétaires, uniquement pour les exigences opérationnelles.
+
+Voici des exemples d’éléments qui peuvent être pris en compte dans la création d’exigences opérationnelles, mais il est important de se rappeler que les règles d’approvisionnement peuvent requérir que les exigences opérationnelles permettent l’offre de logiciels propriétaires et de logiciels libres.
+
+Utilisation des normes internationales ou canadiennes
+
+Les exigences opérationnelles peuvent requérir que la demande sous-jacente soit conforme aux normes internationales ou canadiennes, par exemple, sans toutefois s’y limiter, l’exigence selon laquelle le logiciel soit disponible dans les deux langues officielles.
+
+Flexibilité de la licence
+
+Les licences de logiciels libres peuvent offrir plus de flexibilité qu’une licence propriétaire pour les produits livrables d’un projet numérique.
+
+Lorsque l’exigence opérationnelle profiterait de la réutilisation du logiciel, le GC peut acquérir un logiciel afin de pouvoir l’utiliser dans des projets ultérieurs. Un titulaire de licence propriétaire peut accorder ce droit de réutilisation sur demande, mais par sa nature, tous les logiciels libres sont réutilisables et donc conformes à cette demande par défaut.
+
+Possibilité d’utiliser à n’importe quel usage
+
+Les exigences opérationnelles peuvent être définies de telle sorte que le logiciel puisse être utilisé à n’importe quel usage, sans aucune restriction, ou permettre à d’autres utilisateurs d’utiliser le logiciel. Les conditions du logiciel libre sont plus susceptibles de respecter cette exigence.
+
+Capacité d’évaluer le code
+
+Le GC peut fixer ses exigences de sorte que le code source soit disponible aux fins d’audit par un tiers afin de déterminer la qualité, la fonctionnalité et la sécurité du logiciel.
+
+Harmonisation avec le Gouvernement ouvert
+
+En outre, le GC peut fixer ses exigences de sorte que le code source soit fourni au public afin de permettre une plus grande transparence et de s’harmoniser avec les principes du gouvernement ouvert dans la charte du D9.
+
+Possibilité de distribuer le logiciel
+
+On peut établir des exigences opérationnelles de telle sorte que le logiciel puisse être distribué à n’importe qui, afin de s’assurer que les autres institutions de la Couronne n’aient pas besoin de devenir des clients du fournisseur initial pour accéder aux services fournis par un autre organisme et les utiliser. Par exemple, la Couronne fédérale pourrait souhaiter pouvoir fournir le logiciel sans frais supplémentaires aux institutions provinciales ou municipales.
+
+
diff --git a/fr/guides/publication-code-source-libre.md b/fr/guides/publication-code-source-libre.md
new file mode 100644
index 0000000..69ecc08
--- /dev/null
+++ b/fr/guides/publication-code-source-libre.md
@@ -0,0 +1,293 @@
+# Guide de publication de code source libre
+
+La [Directive sur la gestion des technologies de l’information, annexe C](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249§ion=procedure&p=D#appC), fournit les procédures obligatoires pour l’évaluation de l’architecture intégrée, qui seront utilisées par les Conseils d’examen de l’architecture (CEA) et le CEA intégré du gouvernement du Canada (GC) en tant que cadre d’évaluation pour examiner les initiatives numériques visant à assurer que le GC agit comme unique entreprise et à assurer l’harmonisation ministérielle avec l’orientation numérique du GC.
+
+Ceux-ci s’harmonisent avec les [normes numériques](https://www.canada.ca/fr/gouvernement/systeme/gouvernement-numerique/normes-numeriques-gouvernement-canada.html) et l’exigence aux points C.2.3.8 et C.2.3.9.5 des [Procédures obligatoires pour l’évaluation de l’architecture intégrée](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#claC.2.3.8), qui prévoient que tous les codes sources doivent être publiés sous une licence libre appropriée et lorsqu’il ne l’est pas, il doit être partagé au sein du gouvernement du Canada.
+
+Par conséquent, il est recommandé que, lorsqu’ils ont le droit de le faire, les ministères publient tout leur code source en tant que logiciel libre, que la solution logicielle soit (i) acquise en tant que logiciel libre, (ii) mise au point par les employés du GC à l’interne ou (iii) acquise au moyen des conditions des contrats d’approvisionnement où des conditions de licence appropriées ont été négociées.
+
+Lorsque la divulgation du code en général n’est pas appropriée ou possible, on recommande de commencer par le partage interne du code source à tous les ministères, dans la mesure où les conditions de la licence applicable autorisent ce partage.
+Il faut veiller à ce que la licence accordée au Canada ne limite pas la distribution de ce code à certains ministères utilisateurs.
+Cela permettra de rendre le code source prêt à être rendu public à titre de logiciel libre, lorsque le Canada aura reçu ce droit.
+
+Voici les étapes à suivre pour publier le code source du GC :
+
+1. [Demander les approbations](#1-demander-les-approbations)
+2. [Obtenir les droits de personnaliser le code dans les contrats](#2-obtenir-les-droits-de-personnaliser-le-code-dans-les-contrats)
+3. [Considérer les conséquences de sécurité](#3-considérer-les-conséquences-de-sécurité)
+4. [Choisir une licence libre](#4-choisir-une-licence-libre)
+5. [Choisir un dépôt de code source](#5-choisir-un-dépôt-de-code-source)
+6. [Ajouter les fichiers recommandés](#6-ajouter-les-fichiers-recommandés)
+7. [Publier une ancienne application](#7-publier-une-ancienne-application)
+8. [Travailler dans un environnement ouvert](#8-travailler-dans-un-environnement-ouvert)
+
+## 1. Demander les approbations
+
+### Équipe
+
+La Directive sur la gestion des TI appuie la norme numérique n° 3 : Travailler ouvertement par défaut, au moyen des [Procédures obligatoires pour l’évaluation de l’architecture intégrée (C2.3.8)](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249§ion=procedure&p=C#appC).
+
+Partagez de façon ouverte les données probantes, les résultats de recherche et les prises de décisions.
+Rendez accessibles toutes les données de nature non sensible, tous les renseignements et tout le nouveau code source conçu dans le cadre de la prestation de services, afin que le monde extérieur puisse se les échanger et les réutiliser sous une licence libre.
+
+Conformément à la vision pour un gouvernement ouvert, les équipes devraient par défaut considérer adapter leurs processus afin de développer sous source libre dès le début des projets afin de réduire les coûts indirects liés à la publication ultérieure de leur code source.
+
+Il a également été constaté que cela améliore la qualité du code développé et encourage la collaboration.
+
+### Ministère
+
+Semblable aux données ouvertes ou aux renseignements ouverts visés par la [Directive sur le gouvernement ouvert](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=28108), la publication du code source sous une licence libre exige les approbations du bon ministère ou organisme.
+Cette personne peut varier en fonction du ministère et la délégation devrait être encouragée au niveau le plus bas possible pour encourager la publication du code source libre.
+
+## 2. Obtenir les droits de personnaliser le code dans les contrats
+
+La [Politique sur les droits de propriété intellectuelle](https://www.ic.gc.ca/eic/site/068.nsf/fra/00005.html) issus de marchés conclus avec l’État d’Innovation, Sciences et Développement économique Canada (ISDE) stipule que l’entrepreneur est propriétaire des droits de propriété intellectuelle de base créée à la suite d’un contrat d’achat de l’État.
+Toutefois, lorsque l’utilisation prévue par l’État de la propriété intellectuelle peut être satisfaite par le biais d’accords de licence, elle a la possibilité de rechercher la ou les licence (s) nécessaire (s), qu’elle soit large ou restreinte.
+
+Dans le cadre de la discussion avec l’unité des services juridiques de l’institution et de l’examen de la politique applicable, il convient de noter que le [Guide des clauses et conditions uniformisées d’achat](https://achatsetventes.gc.ca/politiques-et-lignes-directrices/guide-des-clauses-et-conditions-uniformisees-d-achat/5/K/K3030C/2) de Services publics et Approvisionnement Canada (SPAC) renferme des clauses pour demander une [Licence concernant le matériel protégé par des droits d’auteur](https://achatsetventes.gc.ca/politiques-et-lignes-directrices/guide-des-clauses-et-conditions-uniformisees-d-achat/5/K/K3030C/2), qui peut utiliser les clauses des contrats si le ministère ou l’organisme veut que les droits d’auteur sur l’œuvre appartiennent à l’entrepreneur, mais souhaite obtenir une licence pour exercer tous les droits compris dans les droits d’auteur.
+
+Les ministères ou organismes peuvent publier le code développé à la suite d’un contrat d’approvisionnement de l’État sous une licence libre, où ces droits ont été accordés au Canada.
+Le contrat d’approvisionnement pourrait également exiger à l’organisme contractant d’être responsable de la publication du code source sous une licence libre acceptable ou de contribuer directement au logiciel libre existant à l’aide de la licence de ce projet, et ces clauses seraient efficaces lorsqu’acceptées par le fournisseur.
+
+## 3. Considérer les conséquences de sécurité
+
+### Développer un logiciel ouvertement
+
+* Conserver les données sensibles comme les justificatifs d’identité en lieu sûr et séparément du code source.
+* Éviter d’entreposer des clés et d’autres documents de nature délicate dans des systèmes non approuvés à cette fin.
+* L’examen du code augmente la probabilité de détecter les bogues, les vulnérabilités en matière de sécurité et réduit le risque d’engager des données sensibles.
+* Mettre en œuvre des mesures de contrôle suffisantes pour la prévention des changements non autorisés ou accidentels comme signer le code et établir des droits d’accès pour les utilisateurs des dépôts de code.
+* Élaborer des stratégies et des processus d’atténuation pour régler les incidents liés à la sécurité.
+* Intégrer les pratiques de sécurité dans vos processus et méthodes quotidiennes.
+* Tirer parti des outils et services pour automatiser la recherche de vulnérabilités connues, de clés secrètes possibles et de renseignements personnellement identifiables.
+
+## 4. Choisir une licence libre
+
+Lorsque le projet fait partie d’une communauté plus vaste de logiciels libres, telle que des plugiciels, des modules, des extensions ou des travaux dérivés de logiciels libres existants, il est vivement recommandé d’utiliser la licence généralement utilisée par la communauté.
+
+Lorsque le projet est démarré par le GC et qu’il n’est pas lié à une communauté externe, le choix de la licence libre doit être fondé sur les licences des éléments (bibliothèques et cadres tiers) que vous utiliserez et les résultats escomptés.
+
+### Licences permissives recommandées
+
+#### MIT
+
+**Quand utiliser** des petits projets et des scénarios simples.
+
+**Texte de licence** https://opensource.org/licenses/MIT
+
+#### Apache 2.0
+
+**Quand utiliser** de plus grands projets de logiciels qui utilisent Apache 2.0 parce qu’il fournit un octroi de brevets.
+
+**Texte de licence** http://www.apache.org/licenses/LICENSE-2.0.txt
+
+### Licences réciproques recommandées
+
+« GPL 3.0 ou version ultérieure », « LGPL 3.0 ou version ultérieure » et « AGPL 3.0 ou version ultérieure » font référence à la version 3 des licences avec la note « ou version ultérieure ».
+Il ne s’agit pas d’un engagement envers la version future des licences.
+
+#### « GPL 3.0 ou version ultérieure »
+
+**Quand utiliser** le logiciel
+
+**Texte de licence** https://www.gnu.org/licenses/gpl-3.0.txt
+
+#### « LGPL 3.0 ou version ultérieure »
+
+**Quand utiliser** les bibliothèques
+
+**Texte de licence** https://www.gnu.org/licenses/lgpl-3.0.txt
+
+#### « AGPL 3.0 ou version ultérieure »
+
+**Quand utiliser** des applications et des services Web
+
+**Texte de licence** https://www.gnu.org/licenses/agpl-3.0.txt
+
+### Installer une licence
+
+Afin d’appliquer au code source, ajouter le texte de la licence choisie à un fichier LICENSE.txt dans le dossier source du projet.
+Voir [Ajouter les fichiers recommandés](#6-ajouter-les-fichiers-recommandés).
+Vous pouvez aussi ajouter le texte de la licence directement dans l’un de vos fichiers de code source, mais en le rendant clairement disponible à la source de votre projet, vous le rendez plus facile à trouver pour les personnes et certaines plateformes de collaboration peuvent automatiquement afficher votre licence dans l’interface Web.
+
+Si plusieurs licences peuvent être appliquées, choisir une licence qui correspond à l’objectif du projet et ses interactions avec d’autres projets.
+Cela tend à dépendre de la décision d’appliquer une licence réciproque ou permissive.
+
+#### Permissive
+
+**Bénéficiaires du logiciel libre** Tout le monde : maximise la portée des utilisateurs en aval et possède un vaste attrait pour tout le secteur privé...
+une plus grande flexibilité pour que les utilisateurs finaux, les développeurs et les entreprises puissent réutiliser le logiciel comme bon leur semble, y compris dans le cadre de logiciels commerciaux.
+
+**Bénéficiaires des modifications du code en aval** Toute la communauté, mais seulement lorsque l’entreprise, l’organisme ou un développeur individuel choisit d’apporter des modifications à nouveau sous la licence permissive.
+
+**Complexité de la licence** Souvent courte, simple et compréhensible (par exemple MIT).
+
+**Interopérabilité** Le code d’une licence permissive peut être inclus dans les projets visés par des licences réciproques, d’autres licences permissives ou des licences propriétaires.
+
+#### Réciproque
+
+**Bénéficiaires du logiciel libre** Tout le monde : Mais uniquement dans la mesure où ces personnes diffusent leur logiciel selon les mêmes modalités d’octroi de licence dont elles bénéficient.
+Approprié dans les cas où il est important de recevoir les changements en aval, ou lorsqu’il est important de veiller à ce que les travaux fondés sur un investissement initial restent des logiciels libres...
+peut également mettre l’accent de soutenir les autres entreprises du secteur privé qui fournissent des services et du soutien.
+
+**Bénéficiaires des modifications du code en aval** Toute la communauté chaque fois où une entreprise, un organisme ou un développeur individuel distribue les modifications ou contribue aux modifications sous la licence réciproque.
+
+**Complexité de la licence** Jargon juridique relativement long et complexe (par exemple AGPL 3.0).
+
+**Interopérabilité** Un code de licence réciproque ne peut généralement pas être inclus dans un projet sous une autre licence.
+
+#### Principales différences
+
+Les différences parmi la gamme de licences réciproques GPL illustrent comment le type de distribution et l’étendue de l’intégration interagissent pour déterminer dans quelles circonstances une obligation réciproque s’applique, comme le montre le tableau suivant.
+
+##### Œuvre dérivée de l’original
+
+###### Œuvre dérivée de l’original – Distribution du code source
+
+GPLv3 : **Oui** - LGPLv3 : **Oui** - AGPLv3 : **Oui**
+
+###### Œuvre dérivée de l’original – Fourniture d’un accès sur un réseau informatique
+
+GPLv3 : **Non** - LGPLv3 : **Non** - AGPLv3 : **Oui**
+
+##### Œuvre dérivée avec liens vers l’original seulement
+
+###### Œuvre dérivée avec liens vers l’original seulement – Distribution du code source
+
+GPLv3 : **Oui** - LGPLv3 : **Non** - AGPLv3 : **Oui**
+
+###### Œuvre dérivée avec liens vers l’original seulement – Fourniture d’un accès sur un réseau informatique
+
+GPLv3 : **Non** - LGPLv3 : **Non** - AGPLv3 : **Oui**
+
+##### Collection, y compris l’original non modifié
+
+###### Collection, y compris l’original non modifié – Distribution du code source
+
+GPLv3 : **Non** - LGPLv3 : **Non** - AGPLv3 : **Non**
+
+###### Collection, y compris l’original non modifié – Fourniture d’un accès sur un réseau informatique
+
+GPLv3 : **Non** - LGPLv3 : **Non** - AGPLv3 : **Non**
+
+### Droits sortants
+
+Il faut toujours s’assurer que les droits sortants associés à la licence choisie ne dépassent pas les droits entrants de tout élément de logiciel utilisé dans le code source.
+Par exemple, il ne serait pas légalement possible de publier un projet sous une licence MIT (permissive) si les éléments du logiciel utilisés dans celui-ci ont été initialement publiés sous une licence GPL3 (réciproque).
+
+### Droits d’auteur
+
+La [Loi canadienne sur le droit d’auteur (article 2)](https://laws-lois.justice.gc.ca/fra/lois/c-42/page-4.html#h-7) prévoit que, lorsqu’un travail est, ou a été, préparé ou publié par ou sous la direction ou le contrôle de Sa Majesté ou tout ministère, le droit d’auteur sur le travail appartient, sous réserve de tout accord avec l’auteur, à Sa Majesté.
+Cela s’applique à tout code source développé par des employés du gouvernement du Canada.
+Cependant, les employés du gouvernement du Canada ont des [Droits moraux](https://laws-lois.justice.gc.ca/fra/lois/c-42/page-4.html#h-8) et comme auteur d’un travail, ils ont a le droit à l’intégrité du travail et le droit d’être associé au travail à titre d’auteur par nom ou sous un pseudonyme ainsi que le droit à l’anonymat.
+
+### Identification appropriée du droit d’auteur du gouvernement du Canada
+
+Selon l’article des [Demandes de droit d’auteur de la Couronne](https://www.canada.ca/fr/patrimoine-canadien/services/demandes-droit-auteur-couronne.html) trouvé sur Canada.ca, la structure suivante devrait être appliquée pour l’avis de droit d’auteur du gouvernement du Canada.
+
+> Droit d’auteur (c) Sa Majesté la Reine du chef du Canada, représentée par la ministre de (nom légal du ministère), (année de publication).
+
+Remplacer le **(nom légal du ministère)** et **(année de publication)** avec l’information appropriée.
+
+Cet avis devrait être ajouté au fichier LICENSE de votre projet.
+Voir [Ajouter les fichiers recommandés](#6-ajouter-les-fichiers-recommandés).
+
+## 5. Choisir un dépôt de code source
+
+Les dépôts de code source recommandés pour le code source libre du gouvernement du Canada sont les suivants :
+
+* [GitLab](https://gitlab.com/)
+* [GitHub](https://github.com/)
+* [framagit](https://framagit.org/)
+* [Bitbucket](https://bitbucket.org/)
+
+Le gouvernement du Canada a également un dépôt interne de code source à la disposition de tous les ministères et organismes.
+
+* [GCcode](https://gccode.ssc-spc.gc.ca/) (interne au gouvernement du Canada seulement)
+
+### Organismes
+
+Les ministères et les organismes sont libres de choisir la plateforme qui convient le mieux à leurs besoins opérationnels, mais leurs projets devraient, dans la mesure du possible, être tous regroupés sous un organisme ou un groupe unique.
+Cela aiderait la découvrabilité de vos projets, mais aussi contribuerait à augmenter les possibilités de collaboration.
+
+### Système de contrôle des versions
+
+Le système de contrôle des versions recommandé pour le code libre du GC est Git.
+On encourage également les ministères à utiliser Git pour gérer leur code source à l’interne.
+
+## 6. Ajouter les fichiers recommandés
+
+Avant d’être publié, le code source devrait inclure ce qui suit :
+
+* un fichier LICENSE (voir [Choisir une licence libre](#4-choisir-une-licence-libre)) contenant une copie de la licence sous laquelle le code source est publié;
+
+Par défaut, un projet sans une licence libre appliquée serait seulement publié dans le cadre du droit d’auteur de la Couronne.
+
+**Remarque** : La licence libre peut être intégrée directement dans le code source, mais il est fortement recommandé de la mettre dans un fichier LICENSE distinct à la source du répertoire de votre projet.
+
+De plus, les points suivants sont recommandés comme pratique exemplaire :
+
+* Un fichier README.md fournissant de l’information sur le projet, comment l’utiliser et de la documentation générale.
+ * Il est également recommandé que ce fichier soit bilingue pour accroître l’utilisation et la contribution au projet.
+* Un fichier CONTRIBUTING.md expliquant la façon de contribuer au projet.
+* Un fichier SECURITY.md expliquant la politique sur la sécurité, ainsi que les procédures de déclaration de vulnérabilités de sécurité.
+* Un fichier CODE_OF_CONDUCT.md expliquant les valeurs et l’éthique pour les employés du secteur public et pour le projet.
+
+Des exemples de ces fichiers sont disponibles dans le [dépôt de modèles](https://github.com/canada-ca/template-gabarit).
+
+## 7. Publier une ancienne application
+
+Publier une ancienne application peut sembler beaucoup de travail, mais c’est faisable et, en fait, un bon investissement si l’application continuera d’être utilisée dans l’avenir.
+La documentation pourrait être améliorée au cours de la publication du projet pour aider à accroître les contributions de la communauté.
+
+De plus, publier une ancienne application peut mener à sa réutilisation et à accroître le développement des contributions de la part des parties intéressées.
+Cela peut relancer le développement actif de l’application, en lui fournissant des fonctionnalités améliorées et des corrections de bogues.
+
+Les risques de vulnérabilité existent déjà et la publier comme logiciel libre ne change pas leur état.
+Une façon de limiter ces risques est de ne pas fournir les configurations de la version en production.
+
+Des outils d’analyse dotés de fonctionnalités avancées et des tests de sécurité doivent être envisagés pour aider les équipes de développement à accélérer le processus de révision et de nettoyage.
+
+## 8. Travailler dans un environnement ouvert
+
+### Diffuser tôt, diffuser souvent
+
+Il est recommandé que le code source soit publié aussitôt que possible dans le cycle de vie du projet pour éviter les frais de publication du code source plus tard dans le processus.
+Le dépôt du code source public est encouragé à être la seule source de vérité où les développeurs travaillent.
+La plus récente version du code ne signifie pas nécessairement que c’est la version déployée en production.
+
+### Être aux commandes
+
+Lorsque vous travaillez dans les équipes ouvertes, vous contrôlez toujours ce qui entre dans le code source et avez une occasion d’examiner les contributions des développeurs internes et externes.
+Les droits d’accès des dépôts peuvent être configurés afin que seuls les membres autorisés de l’équipe puissent accepter les modifications.
+D’autres peuvent distribuer la version modifiée de votre code, mais cela ne signifie pas que les modifications doivent être acceptées dans le cadre de votre code.
+
+### S’identifier en tant qu’employé du gouvernement du Canada
+
+Les employés devraient utiliser leur nom au complet et l’adresse courriel du gouvernement du Canada pour toutes les contributions de code aux dépôts publics tout en agissant dans l’exercice de leurs fonctions ou de leur emploi.
+
+### Langues officielles
+
+La [Politique sur les langues officielles](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=26160) ne s’applique pas au code source des logiciels (y compris les commentaires).
+Cependant, les mêmes règles sur les LO des autres applications élaborées par le GC ou au nom du GC dans le passé devrait s’appliquer pour ce qui est de la documentation pour l’utilisateur final, que le projet ait été publié ou non comme logiciel libre.
+
+### communauté
+
+Établir une communauté accueillante peut influencer l’avenir et la réputation de votre projet.
+En offrant une expérience positive aux contributeurs et en leur facilitant les interactions avec l’équipe de projet, vous les encouragez à continuer de contribuer.
+Vous devez répondre aux questions, bogues et intégrer les propositions de modifications pour encourager les gens à continuer de vous aider.
+
+Il est recommandé d’inclure un fichier README.md et un fichier CONTRIBUTING.md dans votre code source.
+Voir [Ajouter les fichiers recommandés](#6-ajouter-les-fichiers-recommandés).
+
+### Accord de licence de contributeur
+
+Les projets du gouvernement du Canada n’exigent pas d’accords de licence des contributeurs, mais reposent sur des licences de logiciel libre fournissant les conditions nécessaires.
+Les contributions sont faites sous la même licence sous laquelle le projet est publié et les auteurs conservent le droit d’auteur de leurs contributions.
+
+### Échange de ressources ouvertes
+
+Il est vivement recommandé aux ministères d’ajouter un lien vers les dépôts de code source de leurs projets dans la [section Code source ouvert de l'Échange de ressources ouvertes](https://canada-ca.github.io/ore-ero/fr/index.html).
+Cela permettra de rehausser la visibilité de tous les projets gérés par le GC et potentiellement accroître la collaboration.
+
+Les directives sur la façon de mettre à jour les données peuvent être trouvées sur [GitHub](https://github.com/canada-ca/ore-ero/tree/master/_data#donn%C3%A9es-pour-l%C3%A9change-de-ressources-ouvert).
diff --git a/fr/guides/publication-code-source-ouvert.md b/fr/guides/publication-code-source-ouvert.md
deleted file mode 100644
index 727eb09..0000000
--- a/fr/guides/publication-code-source-ouvert.md
+++ /dev/null
@@ -1,247 +0,0 @@
-# Guide pour la publication du code source libre
-
-La [Directive sur la gestion des technologies de l’information](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249§ion=procedure&p=D#appC), annexe C, fournit les procédures obligatoires pour l’évaluation de l’architecture intégrée, qui seront utilisées par les Conseils d’examen de l’architecture (CEA) et le CEA intégré du gouvernement du Canada (GC) en tant que cadre d’évaluation pour examiner les initiatives numériques visant à assurer que le GC agit comme unique entreprise et à assurer l’harmonisation ministérielle avec l’orientation numérique du GC.
-
-Ceux-ci s’harmonisent avec les [normes numériques](https://www.canada.ca/fr/gouvernement/systeme/gouvernement-numerique/normes-numeriques-gouvernement-canada.html) et l’exigence aux points C.2.3.8 et C.2.3.9.5 des [Procédures obligatoires pour l’évaluation de l’architecture intégrée](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#claC.2.3.8), qui prévoient que tous les codes sources doivent être publiés sous une licence de logiciel libre appropriée et lorsqu’il ne l’est pas, il doit être partagé au sein du gouvernement du Canada.
-
-Par conséquent, il est recommandé que, lorsqu’ils ont le droit de le faire, les ministères publient tout le code source en tant que logiciel libre, que la solution logicielle soit (i) acquise en tant que logiciel libre, (ii) mise au point par les employés du GC à l’interne ou (iii) acquise au moyen des conditions des contrats d’approvisionnement où des conditions de licence appropriées ont été négociées.
-
-Lorsque la divulgation du code en général n’est pas appropriée ou possible, on recommande de commencer par le partage interne du code source à tous les ministères, dans la mesure où les conditions de la licence applicable autorisent ce partage. Il faut veiller à ce que la licence accordée au Canada ne limite pas la distribution de ce code à certains ministères utilisateurs. Cela permettra de rendre le code source prêt à être rendu public à titre de source ouverte, lorsque le Canada aura reçu ce droit.
-
-Voici les étapes à suivre pour publier le code source du GC :
-
-1. [Demander les approbations](#demander-les-approbations)
-2. [Obtenir les droits de personnaliser le code dans les contrats](#obtenir-les-droits-de-personnaliser-le-code-dans-les-contrats)
-3. [Considérer les conséquences de sécurité](#considérer-les-conséquences-de-sécurité)
-4. [Choisir une licence des logiciels libres](#choisir-une-licence-des-logiciels-libres)
-5. [Choisir un dépôt de code source](#choisir-un-dépôt-de-code-source)
-6. [Ajouter des fichiers recommandés](#ajouter-des-fichiers-recommandés)
-7. [Publier une ancienne application](#publier-une-ancienne-application)
-8. [Travailler dans un environnement ouvert](#travailler-dans-un-environnement-ouvert)
-
-## Demander les approbations
-
-### Équipe
-
-La Directive sur la gestion des TI appuie la norme numérique n° 3 : Travailler ouvertement par défaut, au moyen des [Procédures obligatoires pour l’évaluation de l’architecture intégrée (C2.3.8)](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249§ion=procedure&p=C#appC).
-
-Partagez de façon ouverte les données probantes, les résultats de recherche et les prises de décisions. Rendez accessibles toutes les données de nature non sensible, tous les renseignements et tous les nouveaux codes source conçus dans le cadre de la prestation de services, afin que le monde extérieur puisse se les échanger et les réutiliser sous une licence ouverte.
-
-Conformément à la vision pour un gouvernement ouvert, les équipes devraient par défaut considérer adapter leurs processus afin de se développer en tant que source ouverte dès le début des projets afin de réduire les coûts indirects liés à la publication ultérieure de leur code source.
-
-Il a également été constaté que cela améliore la qualité du code développé et encourage la collaboration.
-
-### Ministère
-
-Semblable aux données ouvertes ou aux renseignements ouverts visés par la [Directive sur le gouvernement ouvert](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=28108), la publication du code source sous une licence de logiciel libre exige les approbations du bon ministère ou organisme.
-Cette personne peut varier en fonction du ministère et la délégation devrait être encouragée au niveau le plus bas possible pour encourager la publication du code source libre.
-
-## Obtenir les droits de personnaliser le code dans les contrats
-
-La [Politique sur les droits de propriété intellectuelle](https://www.ic.gc.ca/eic/site/068.nsf/fra/00005.html) issus de marchés conclus avec l’État d’Innovation, Sciences et Développement économique Canada (ISDE) stipule que l’entrepreneur est propriétaire des droits de propriété intellectuelle de base créée à la suite d’un contrat d’achat de l’État. Toutefois, lorsque l’utilisation prévue par l’État de la propriété intellectuelle peut être satisfaite par le biais d’accords de licence, elle a la possibilité de rechercher la ou les licence (s) nécessaire (s), qu’elle soit large ou restreinte.
-
-Dans le cadre de la discussion avec l’unité des services juridiques de l’institution et de l’examen de la politique applicable, il convient de noter que le [Guide des clauses et conditions uniformisées d’achat](https://achatsetventes.gc.ca/politiques-et-lignes-directrices/guide-des-clauses-et-conditions-uniformisees-d-achat/5/K/K3030C/2) de Services publics et Approvisionnement Canada (SPAC) renferme des clauses pour demander une [Licence concernant le matériel protégé par des droits d’auteur](https://achatsetventes.gc.ca/politiques-et-lignes-directrices/guide-des-clauses-et-conditions-uniformisees-d-achat/5/K/K3030C/2), qui peut utiliser les clauses des contrats si le ministère ou l’organisme veut que les droits d’auteur sur l’œuvre appartiennent à l’entrepreneur, mais souhaite obtenir une licence pour exercer tous les droits compris dans les droits d’auteur.
-
-Les ministères ou organismes peuvent publier le code développé à la suite d’un contrat d’approvisionnement de l’État sous une licence de logiciel libre, où ces droits ont été accordés au Canada. Le contrat d’approvisionnement pourrait également exiger à l’organisme contractant d’être responsable de la publication du code source sous une licence de logiciel libre acceptable ou de contribuer directement au logiciel libre existant à l’aide de la licence de ce projet, et ces clauses seraient efficaces si convenues par le fournisseur.
-
-## Considérer les conséquences de sécurité
-
-### Développer un logiciel ouvertement
-
-* Conserver les données sensibles comme les justificatifs d’identité en lieu sûr et séparément du code source.
-* Éviter d’entreposer des clés et d’autres documents de nature délicate dans des systèmes non approuvés à cette fin.
-* L’examen des codes augmente la probabilité de détecter les bogues, les vulnérabilités en matière de sécurité et réduit le risque d’engager des données sensibles.
-* Mettre en œuvre des mesures de contrôle suffisantes pour la prévention des changements non autorisés ou accidentels comme signer le code et établir des droits d’accès pour les utilisateurs des dépôts de code.
-* Élaborer des stratégies d’atténuation et de processus pour régler les incidents liés à la sécurité.
-* Intégrer les pratiques de sécurité dans vos processus et méthodes quotidiennes.
-* Tirer parti des outils et services pour automatiser la recherche de vulnérabilités connues, de clés secrètes possibles et de renseignements personnellement identifiables.
-
-## Choisir une licence des logiciels libres
-
-Lorsque le projet fait partie d’une collectivité plus vaste de logiciels libres, telle que des plug-ins, des modules, des extensions ou des travaux dérivés de logiciels libres existants, il est vivement recommandé d’utiliser la licence généralement utilisée par la collectivité.
-
-Lorsque le projet est démarré par le GC lui-même et qu’il n’est pas lié à une collectivité externe, le choix de la licence libre doit être fondé sur les licences des éléments (bibliothèques et cadres tiers) que vous utiliserez et les résultats escomptés.
-
-### Licences permissives recommandées
-
-#### MIT
-
-**Quand utiliser** des petits projets et des scénarios simples.
-**Texte de licence** https://opensource.org/licenses/MIT
-
-#### Apache 2.0
-
-**Quand utiliser** de plus grands projets de logiciels qui utilisent Apache 2.0 parce qu’il fournit un octroi de brevets.
-**Texte de licence** http://www.apache.org/licenses/LICENSE-2.0.txt
-
-### Licences réciproques recommandées
-
-« GPL 3.0 ou version ultérieure », « LGPL 3.0 ou version ultérieure » et « AGPL 3.0 ou version ultérieure » font référence à la version 3 des licences avec la note « ou version ultérieure ». Il ne s’agit pas d’un engagement envers la version future des licences.
-
-#### « GPL 3.0 ou version ultérieure »
-
-**Quand utiliser** le logiciel
-**Texte de licence** https://www.gnu.org/licenses/gpl-3.0.txt
-
-#### « LGPL 3.0 ou version ultérieure »
-
-**Quand utiliser** les bibliothèques
-**Texte de licence** https://www.gnu.org/licenses/lgpl-3.0.txt
-
-#### « AGPL 3.0 ou version ultérieure »
-
-**Quand utiliser** des applications et des services Web
-**Texte de licence** https://www.gnu.org/licenses/agpl-3.0.txt
-
-### Installer une licence
-
-Afin d’appliquer le code source, ajouter le texte de la licence choisie à un fichier LICENCE.txt dans le dossier source du projet. Voir [Ajouter des fichiers recommandés](#ajouter-des-fichiers-recommandés). Vous pouvez aussi ajouter le texte de la licence directement dans l’un de vos fichiers de code source, mais en le rendant clairement disponible à la source de votre projet, vous le rendez plus facile à trouver pour les personnes qui le cherchent et certaines plateformes de collaboration peuvent automatiquement afficher votre licence sur l’interface Web.
-
-Si plusieurs licences peuvent être appliquées, choisir une licence qui correspond à l’objectif du projet et ses interactions avec d’autres projets. Cela tend à dépendre de la décision d’appliquer une licence réciproque ou permissive.
-
-#### Permissive
-
-**Bénéficiaires du lancement du logiciel libre** Tout le monde : maximise la portée des utilisateurs en aval et a un vaste appel de tout le secteur privé... une plus grande flexibilité pour que les utilisateurs finaux, les développeurs et les entreprises puissent réutiliser le logiciel comme bon leur semble, y compris dans le cadre de logiciels commerciaux.
-
-**Bénéficiaires des modifications du code en aval** Toute la collectivité, mais seulement lorsque l’entreprise, l’organisme ou un développeur individuel choisit d’apporter des modifications en vertu de la licence permissive.
-
-**Complexité des licences** Souvent courte, simple et compréhensible (par exemple MIT).
-
-**Interopérabilité** Le code d’une licence permissive peut être inclus dans les projets visés par des licences réciproques, d’autres licences permissives ou des licences propriétaires.
-
-#### Réciproque
-
-**Bénéficiaires du lancement du logiciel libre** Tout le monde : Mais uniquement dans la mesure où ces personnes diffusent leur logiciel selon les mêmes modalités d’octroi de licence dont elles bénéficient. Approprié dans les cas où il est important de recevoir les changements en aval, ou lorsqu’il est important de veiller à ce que les travaux fondés sur un investissement initial restent des logiciels libres et à source ouverte... peut également mettre l’accent sur les autres entreprises du secteur privé qui fournissent des services et du soutien.
-
-**Bénéficiaires des modifications du code en aval** Toute la collectivité chaque fois où une entreprise, un organisme ou un développeur individuel distribue les modifications ou contribue aux modifications sous la licence réciproque.
-
-**Complexité des licences** Jargon juridique relativement long et complexe (par exemple AGPL 3.0).
-
-**Interopérabilité** Un code de licence réciproque ne peut généralement pas être inclus dans un projet en vertu d’une autre licence.
-
-#### Principales différences
-
-Les différences parmi la gamme de licences réciproques GPL illustrent comment le type de distribution et l’étendue de l’intégration interagissent pour déterminer dans quelles circonstances une obligation réciproque s’applique, comme le montre le tableau suivant.
-
-##### Œuvre dérivée de l’original
-
-Œuvre dérivée de l’original – Distribution du code source
-GPLv3 : Oui - LGPLv3 : Oui - AGPLv3 : Oui
-Œuvre dérivée de l’original – Fourniture d’un accès sur un réseau informatique
-GPLv3 : Non - LGPLv3 : Non - AGPLv3 : Oui
-
-##### Œuvre dérivée avec liens vers l’original seulement
-
-Œuvre dérivée avec liens vers l’original seulement – Distribution du code source
-GPLv3 : Oui - LGPLv3 : Non - AGPLv3 : Oui
-Œuvre dérivée avec liens vers l’original seulement – Fourniture d’un accès sur un réseau informatique
-GPLv3 : Non - LGPLv3 : Non - AGPLv3 : Oui
-Collection, y compris l’original non modifié.
-Collection, y compris l’original non modifié – Distribution du code source
-GPLv3 : Non - LGPLv3 : Non - AGPLv3 : Non
-Collection, y compris l’original non modifié – Fourniture d’un accès sur un réseau informatique
-GPLv3 : Non - LGPLv3 : Non - AGPLv3 : Non
-
-### Droits sortants
-
-Il faut toujours s’assurer que les droits sortants associés à la licence choisie ne dépassent pas les droits entrants de tout élément de logiciel utilisé dans le code source. Par exemple, il ne serait pas légalement possible de publier un projet sous une licence MIT (permissive) si les éléments du logiciel utilisés dans celui-ci ont été initialement publiés sous une licence GPL3 (réciproque).
-
-### Droits d’auteur
-
-La [Loi canadienne sur le droit d’auteur (article 2)](https://laws-lois.justice.gc.ca/fra/lois/c-42/page-4.html#h-7) prévoit que, lorsqu’un travail est, ou a été, préparé ou publié par ou sous la direction ou le contrôle de Sa Majesté ou tout ministère, le droit d’auteur sur le travail appartient, sous réserve de tout accord avec l’auteur, à Sa Majesté. Cela s’applique à tout code source développé par des employés du gouvernement du Canada.
-Cependant, les employés du gouvernement du Canada ont des [Droits moraux](https://laws-lois.justice.gc.ca/fra/lois/c-42/page-4.html#h-8) et comme l’auteur d’un travail a le droit à l’intégrité du travail et le droit d’être associé au travail à titre d’auteur par nom ou sous un pseudonyme ainsi que le droit à l’anonymat.
-
-### Identification appropriée du droit d’auteur du gouvernement du Canada
-
-Selon l’article des [Demandes de droit d’auteur de la Couronne](https://www.canada.ca/fr/patrimoine-canadien/services/demandes-droit-auteur-couronne.html) trouvé sur Canada.ca, la structure suivante devrait être appliquée pour l’avis de droit d’auteur du gouvernement du Canada.
-
-Droit d’auteur (c) Sa Majesté la Reine du chef du Canada, représentée par la ministre de (nom légal du ministère), (année de publication).
-Remplacer le (nom légal du ministère) et (année de publication) avec l’information appropriée.
-
-Cet avis devrait être ajouté au fichier LICENCE dans votre projet. Voir [Ajouter des fichiers recommandés](#ajouter-des-fichiers-recommandés).
-
-## Choisir un dépôt de code source
-
-Les dépôts de code source recommandés pour le code source libre du gouvernement du Canada sont les suivants :
-
-* GitLab
-* GitHub
-* framagit
-* Bitbucket
-
-Le gouvernement du Canada a également un dépôt interne de code source à la disposition de tous les ministères et organismes.
-
-* GCcode (interne au gouvernement du Canada seulement)
-
-### Organismes
-
-Les ministères et les organismes sont libres de choisir la plateforme qui convient le mieux à leurs besoins opérationnels, mais leurs projets devraient, dans la mesure du possible, être tous regroupés sous un organisme ou un groupe unique. Cela aiderait la découvrabilité de vos projets, mais aussi contribuerait à augmenter les possibilités de collaboration.
-
-### Système de contrôle des versions
-
-Le système de contrôle des versions recommandé pour le code source ouvert GC est Git. On encourage également les ministères à utiliser Git pour gérer leur code source à l’interne.
-
-## Ajouter des fichiers recommandés
-
-Avant d’être publié, le code source devrait inclure ce qui suit :
-
-* un fichier LICENCE (voir [Choisir une licence des logiciels libres](#choisir-une-licence-des-logiciels-libres)) contenant une copie de la licence sous laquelle le code source est publié;
-
-Par défaut, un projet sans une licence de logiciel libre appliquée serait seulement publié dans le cadre du droit d’auteur de la Couronne.
-
-**Remarque** : La licence à source ouverte elle-même peut être appliquée directement au code source, mais il est fortement recommandé de la mettre dans un fichier LICENCE distinct à la source du répertoire de votre projet.
-
-De plus, les points suivants sont recommandés comme pratique exemplaire :
-
-* Un fichier README.md fournissant de l’information sur le projet, comment l’utiliser et de la documentation sur le projet.
- * Il est également recommandé que ce dossier soit bilingue pour accroître l’utilisation et la contribution au projet.
-* Un fichier CONTRIBUTING.md expliquant la façon de contribuer à la réalisation du projet.
-* Un fichier SECURITY.md expliquant la politique sur la sécurité, ainsi que les procédures de déclaration des vulnérabilités en matière de sécurité.
-* Un fichier CODE_OF_CONDUCT.md expliquant les valeurs et l’éthique pour les employés du secteur public et pour le projet.
-
-Des exemples de ces fichiers sont disponibles dans le [dépôt de modèles](https://github.com/canada-ca/template-gabarit).
-
-## Publier une ancienne application
-
-Publier une ancienne application peut sembler beaucoup de travail, mais c’est faisable et, en fait, un bon investissement si l’application continuera d’être utilisée à l’avenir. La documentation pourrait être améliorée au cours de la publication du projet pour aider à accroître les contributions de la collectivité.
-
-De plus, publier une ancienne application peut mener à sa réutilisation et à accroître le développement des contributions de la part des parties intéressées. Cela peut relancer le développement actif de l’application, en lui fournissant des fonctionnalités améliorées et des corrections de bogues.
-
-Les risques de vulnérabilité existent déjà et la publier comme source ouverte ne change pas leur état. Une façon de limiter ces risques est de ne pas fournir les configurations de la version de production.
-
-Des outils d’analyse dotés de fonctionnalités avancées et des tests de sécurité doivent être envisagés pour aider les équipes de développement à accélérer le processus de révision et de nettoyage.
-
-## Travailler dans un environnement ouvert
-
-### Diffuser tôt, diffuser souvent
-
-Il est recommandé que le code source soit publié aussitôt que possible dans le cycle de vie du projet pour éviter les frais de publication du code source plus tard dans le processus. Le dépôt du code source public est encouragé à être la seule source de vérité où les développeurs travaillent. La plus récente version du code ne signifie pas nécessairement que c’est la version déployée en production.
-
-### Être aux commandes
-
-Lorsque vous travaillez dans les équipes ouvertes, vous contrôlez toujours ce qui entre dans le code source et une occasion d’examiner les contributions des développeurs internes et externes. Les droits d’accès peuvent être configurés pour les référentiels afin que seuls les membres autorisés de l’équipe puissent accepter les modifications. D’autres peuvent distribuer la version modifiée de votre code, mais cela ne signifie pas que les modifications doivent être acceptées dans le cadre de votre code.
-
-### S’identifier en tant qu’employé du gouvernement du Canada
-
-Les employés devraient utiliser leur nom au complet et l’adresse courriel du gouvernement du Canada pour toutes les contributions de code aux répertoires publics tout en agissant dans l’exercice de leurs fonctions ou de leur emploi.
-
-### Langues officielles
-
-La [Politique sur les langues officielles](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=26160) ne s’applique pas aux codes sources des logiciels (y compris les commentaires en ligne).
-Cependant, les mêmes règles sur les LO comme toute autre application élaborée par le GC ou au nom du GC dans le passé devrait s’appliquer pour ce qui est de la documentation de l’utilisateur final, si le projet a été publié ou non comme logiciel libre.
-
-### Collectivité
-
-Établir une collectivité accueillante peut influencer l’avenir et la réputation de votre projet. En offrant une expérience positive aux contributeurs et en leur facilitant les interactions avec l’équipe de projet, vous les encouragez à continuer de contribuer. Vous devez répondre aux questions, bogues et fusionner les demandes pour encourager les gens à continuer de vous aider.
-
-Il est recommandé d’inclure un fichier README.md et un fichier CONTRIBUTING.md avec votre code source. Voir [Ajouter des fichiers recommandés]((#ajouter-des-fichiers-recommandés)).
-
-### Accord de licence de contributeur
-
-Les projets du gouvernement du Canada n’exigent pas d’accords de licence des contributeurs, mais reposent sur des licences de logiciel libre fournissant les conditions nécessaires. Les contributions sont faites sous la même licence sous laquelle le projet est publié et les auteurs conservent leurs droits d’auteur pour leurs contributions.
-
-### Échange de ressources ouvertes
-
-Il est vivement recommandé aux ministères d’ajouter un lien vers les dépôts de code source de leurs projets dans la [section de code source libre d’Échange de ressources ouvertes](https://canada-ca.github.io/ore-ero/fr/index.html). Cela permettra de rehausser la visibilité de tous les projets gérés par le GC et potentiellement accroître la collaboration.
-
-Les directives sur la façon de mettre à jour les données peuvent être trouvées sur [GitHub](https://github.com/canada-ca/ore-ero/tree/master/_data#donn%C3%A9es-pour-l%C3%A9change-de-ressources-ouvert).
diff --git a/fr/guides/utilisation-logiciels-libres.md b/fr/guides/utilisation-logiciels-libres.md
index ce9664a..3ce0c56 100644
--- a/fr/guides/utilisation-logiciels-libres.md
+++ b/fr/guides/utilisation-logiciels-libres.md
@@ -1,75 +1,97 @@
-# Guide pour l’utilisation de logiciels libres
+# Guide d'utilisation de logiciels libres
-La [Directive sur la gestion des technologies de l’information](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#appC), annexe C, fournit les procédures obligatoires pour l’évaluation de l’architecture intégrée, qui seront utilisées par les Conseils d’examen de l’architecture (CEA) et le CEA intégré du gouvernement du Canada (GC) en tant que cadre d’évaluation pour examiner les initiatives numériques visant à assurer que le GC agit comme unique entreprise et à assurer l’harmonisation ministérielle avec l’orientation numérique du GC.
+La [Directive sur la gestion des technologies de l’information, annexe C](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#appC), fournit les procédures obligatoires pour l’évaluation de l’architecture intégrée, qui seront utilisées par les Conseils d’examen de l’architecture (CEA) et le CEA intégré du gouvernement du Canada (GC) en tant que cadre d’évaluation pour examiner les initiatives numériques visant à assurer que le GC agit comme unique entreprise et à assurer l’harmonisation ministérielle avec l’orientation numérique du GC.
-Celles-ci s’harmonisent avec les [Normes numériques](https://www.canada.ca/fr/gouvernement/systeme/gouvernement-numerique/normes-numeriques-gouvernement-canada.html) et l’exigence C.2.3.8 des [Procédures obligatoires pour l’évaluation de l’architecture intégrée](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#claC.2.3.8) qui prévoient que, dans la mesure du possible, des logiciels libres soient utilisés en premier.
+Celles-ci s’harmonisent avec les [Normes numériques](https://www.canada.ca/fr/gouvernement/systeme/gouvernement-numerique/normes-numeriques-gouvernement-canada.html) et [l’exigence C.2.3.8 des Procédures obligatoires pour l’évaluation de l’architecture intégrée](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#claC.2.3.8) qui prévoient que, dans la mesure du possible, des logiciels libres soient utilisés en premier.
Les étapes à suivre pour que le GC utilise des logiciels libres sont les suivantes:
-1. [Envisager activement et équitablement les logiciels libres](#envisager-activement-et-équitablement-les-logiciels-libres)
-2. [Vérifier la propriété ou la licence des logiciels libres](#vérifier-la-propriété-ou-la-licence-des-logiciels-libres)
-3. [Évaluer les options de soutien](#Évaluer-les-options-de-soutien)
-4. [Utiliser les logiciels libres sans modification](#utiliser-les-logiciels-libres-sans-modification)
-5. [Utiliser les logiciels libres avec modifications](#utiliser-les-logiciels-libres-avec-modifications)
-6. [S’inscrire à l’Échange de ressources ouvertes](#s’inscrire-à-l’Échange-de-ressources-ouvertes)
+1. [Envisager activement et équitablement les logiciels libres](#1-envisager-activement-et-équitablement-les-logiciels-libres)
+2. [Vérifier la propriété ou la licence libre](#2-vérifier-la-propriété-ou-la-licence-libre)
+3. [Évaluer les options de soutien](#3-évaluer-les-options-de-soutien)
+4. [Utiliser les logiciels libres sans modification](#4-utiliser-les-logiciels-libres-sans-modification)
+5. [Utiliser les logiciels libres avec modifications](#5-utiliser-les-logiciels-libres-avec-modifications)
+6. [S’inscrire à l’Échange de ressources ouvertes](#6-sinscrire-à-léchange-de-ressources-ouvertes)
-## Envisager activement et équitablement les logiciels libres
+## 1. Envisager activement et équitablement les logiciels libres
Il faut être conscient que les logiciels libres ne sont pas complètement gratuits, on doit donc tenir compte du coût total de possession (CTP) de la migration, y compris les coûts de sortie, de transition et de soutien.
-### Être conscient des bases ouvertes
+### Être conscient du « Open Core » (cœur ouvert)
-Une solution fondée sur un logiciel libre, mais qui nécessite l’utilisation d’éléments privés ne devrait pas être considérée comme un logiciel libre pour les besoins du présent guide. Le modèle de développement à base ouverte est celui où les fournisseurs n’ouvrent que des parties de leur logiciel, donnent accès seulement à une partie du logiciel, puis entourent le reste d’offres privées, ainsi que le modèle où un utilisateur comme le Canada augmente les logiciels propriétaires déjà sous licence avec les logiciels libres. Les versions « gratuites » de logiciels ouverts souvent qualifiées d’éditions « communautaires » sont recommandées en premier. Voir [Vérifier la propriété ou la licence des logiciels libres](#vérifier-la-propriété-ou-la-licence-des-logiciels-libres).
+Une solution fondée sur un logiciel libre, mais qui nécessite l’utilisation d’éléments privés ne devrait pas être considérée comme un logiciel libre pour les besoins du présent guide.
+Le modèle de développement « Open Core » est celui où les fournisseurs n’ouvrent que des parties de leur logiciel et entourent le reste d’éléments fermés, ainsi que le modèle où un utilisateur comme le Canada bonifie un logiciel propriétaire avec des logiciels libres.
+Les versions « gratuites » de ces logiciels libres, souvent qualifiées d’éditions « communautaires », sont recommandées en premier.
+Voir [Vérifier la propriété ou la licence des logiciels libres](#2-vérifier-la-propriété-ou-la-licence-libre).
-### Choisir des logiciels ouverts en priorité
+### Choisir des logiciels libres en priorité
-Les procédures obligatoires pour l’évaluation de l’architecture intégrée ([voir l’annexe C de la Directive sur la gestion des technologies de l’information](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#appC)) nécessitent une architecture d’application – pour la nouvelle technologie ainsi que la mise à niveau ou la migration des solutions existantes – afin de prioriser l’utilisation de logiciels libres de même que les normes ouvertes. Ce faisant, on maximise la substituabilité et l’interopérabilité des éléments de logiciels et ouvre la voie à la création de solutions très souples. Cela aide également à atténuer les risques importants liés au blocage et à des problèmes semblables.
+Les procédures obligatoires pour l’évaluation de l’architecture intégrée voir ([l’annexe C de la Directive sur la gestion des technologies de l’information](https://www.tbs-sct.gc.ca/pol/doc-fra.aspx?id=15249#appC)) nécessitent une architecture d’application – pour une nouvelle technologie ainsi que pour la mise à niveau ou la migration de solutions existantes – afin de prioriser l’utilisation de logiciels libres de même que les normes ouvertes.
+Ce faisant, on maximise la substituabilité et l’interopérabilité des éléments de logiciels et ouvre la voie à la création de solutions très souples.
+Cela aide également à atténuer les risques importants liés au verrouillage (« lock-in ») et à des problèmes semblables.
-Parfois, une solution libre satisfait la plupart des besoins de l’utilisateur, mais exigerait des investissements supplémentaires pour développer la fonctionnalité manquante (voir le Guide de contribution aux logiciels libres). Dans ces cas, cet investissement doit être considéré en pondérant le coût total de possession par rapport à ceux des autres solutions candidates.
+Parfois, une solution libre satisfait la plupart des besoins des utilisateurs, mais exigerait des investissements supplémentaires pour développer une fonctionnalité manquante (voir le [Guide de contribution aux logiciels libres](contribution-logiciels-libres.md)).
+
+Dans ces cas, cet investissement doit être considéré en pondérant le coût total de possession par rapport à ceux des autres solutions potentielles.
### Évaluation
-Les mêmes facteurs qui s’appliquent à l’évaluation de l’ensemble de caractéristiques et de la maturité de logiciels exclusifs s’appliquent également aux logiciels libres. D’autres critères devraient être évalués lors de l’évaluation des logiciels libres :
+Les mêmes facteurs qui s’appliquent à l’évaluation de l’ensemble de caractéristiques et de la maturité des logiciels propriétaires s’appliquent également aux logiciels libres.
+D’autres critères devraient être évalués lors de l’évaluation des logiciels libres :
+
+#### 1. Communauté d'utilisateurs
+
+Une forte communauté d’utilisateurs participant à un projet permet aux gens de répondre aux questions, de procéder à la mise à l’essai du logiciel, de signaler les bogues, de suggérer des améliorations et de susciter un intérêt général pour le logiciel.
+Examinez le dépôt de code public du logiciel et vérifiez la popularité du projet en regardant le nombre de « j’aime » et d’abonnés.
+Vérifiez l’activité du projet par rapport aux utilisateurs en examinant les problèmes et le temps entre les réponses.
+
+#### 2. Communauté de développeurs
-1. Collectivité des utilisateurs
+Une forte communauté de développeurs ayant des antécédents de publication et une participation continue tend à démontrer que les correctifs et les améliorations aux logiciels se poursuivront à l’avenir.
+Observez qui sont les principaux développeurs et qui appuie le projet et la communauté, comme un organisme sans but lucratif.
+Vérifiez le moment du lancement du projet, le rythme selon lequel les versions sont sorties et les réponses aux demandes d'intégration de code provenant des contributeurs.
-Une forte collectivité d’utilisateurs participant à un projet permet aux gens de répondre aux questions, de procéder à la mise à l’essai des logiciels, de signaler les bogues, de suggérer des améliorations et de susciter un intérêt général pour les logiciels. Examinez le dépôt de code public du logiciel et vérifiez la popularité du projet en regardant le nombre de « j’aime » et d’abonnés. Vérifiez l’activité du projet par rapport aux utilisateurs en examinant les problèmes et le temps entre les réponses.
-2. Collectivité des développeurs
+#### 3. Documentation
-Une forte collectivité de développeurs ayant des antécédents de publication et une participation continue tend à démontrer que les correctifs et les améliorations aux logiciels se poursuivront à l’avenir. Observez qui sont les principaux développeurs et qui appuie le projet et la collectivité, comme un organisme sans but lucratif. Vérifiez le moment du lancement du projet, le rythme selon lequel les versions sont sorties et les réponses aux demandes de fusion de code provenant des contributeurs.
-3. Documentation
+La documentation de l’utilisateur fournit des renseignements importants pour aider les utilisateurs à installer le logiciel et à utiliser ses fonctions.
+La documentation technique fournit les exigences et les instructions pour l’installation, le développement, le déploiement et la configuration du logiciel.
-La documentation de l’utilisateur fournit des renseignements importants pour aider les utilisateurs à installer le logiciel et à utiliser ses fonctions. La documentation technique fournit les exigences et les instructions pour l’installation, le développement, le déploiement et la configuration du logiciel.
-4. Évaluations de la sécurité
+#### 4. Évaluations de la sécurité
-Bien que le code des logiciels libres soit vérifiable, cela ne signifie pas nécessairement qu’il est sécurisé. La qualité du code et le temps de réponse habituel pour corriger les lacunes de sécurité aident à indiquer le niveau de sécurité mature du logiciel.
-Comme pour tout logiciel, vous devriez maintenir les pratiques exemplaires et avoir un processus en place pour énumérer toutes les trousses en utilisation de même que leur version afin de les corriger rapidement.
+Bien que le code des logiciels libres soit vérifiable, cela ne signifie pas nécessairement qu’il est sécuritaire.
+La qualité du code et le temps de réponse habituel pour corriger les lacunes de sécurité aident à indiquer le niveau de maturité de la sécurité du logiciel.
+Comme pour tout logiciel, vous devriez maintenir les pratiques exemplaires et avoir un processus en place pour énumérer tous les paquets en utilisation de même que leur version afin de les corriger rapidement.
-## Vérifier la propriété ou la licence des logiciels libres
+## 2. Vérifier la propriété ou la licence libre
-Chaque fois que l’État envisage d’obtenir des logiciels en vertu d’une licence à source ouverte, les ministères devraient examiner les modalités pour valider s’ils peuvent accepter et se conformer à celles ci compte tenu de leur contexte opérationnel particulier.
+Chaque fois que l’État envisage d’obtenir des logiciels sous licence libre, les ministères devraient examiner les modalités pour vérifier s’ils peuvent accepter et se conformer à celles-ci compte tenu de leur contexte opérationnel particulier.
-Le logiciel est habituellement fourni « tel quel », ce qui signifie que la collectivité n’acceptera pas la responsabilité ou ne fournira pas de compensation financière à l’État pour l’interruption de service, la perte de données ou la perte de confidentialité. Par conséquent, vous devriez considérer le logiciel obtenu sous licence de logiciel libre avec les mêmes objectifs de responsabilité que si vous l’aviez écrit.
+Le logiciel est habituellement fourni « tel quel », ce qui signifie que la communauté n’acceptera pas la responsabilité ou ne fournira pas de compensation financière à l’État pour l’interruption de service, la perte de données ou la perte de confidentialité.
+Par conséquent, vous devriez considérer le logiciel obtenu sous licence libre avec les mêmes objectifs de responsabilité que si vous l’aviez développé.
-Tous les logiciels sous une [licence approuvée par Open Source Initiative](https://opensource.org/licenses/alphabetical) ou une [licence de logiciels gratuits de Free Software Foundation](https://www.gnu.org/licenses/license-list.html#SoftwareLicenses) sont considérés comme des logiciels libres, et peuvent être utilisés par le GC [sans modification](#utiliser-les-logiciels-libres-sans-modification), dans la mesure du possible et conformément au présent guide.
+Tous les logiciels sous une [licence approuvée par la Open Source Initiative](https://opensource.org/licenses/alphabetical) ou la [Free Software Foundation](https://www.gnu.org/licenses/license-list.html#SoftwareLicenses) sont considérés comme des logiciels libres, et peuvent être utilisés par le GC [sans modification](#4-utiliser-les-logiciels-libres-sans-modification), dans la mesure du possible et conformément au présent guide.
-Toutefois, si le logiciel doit être modifié, les considérations suivantes doivent être abordées avec les intervenants appropriés (c’est-à-dire, les utilisateurs finaux, les gestionnaires de projet, les services juridiques) et appliquées afin de déterminer les conditions de licence que le Ministère est disposé à approuver.
+Toutefois, si le logiciel doit être modifié, les considérations suivantes doivent être abordées avec les intervenants appropriés (c’est-à-dire, les utilisateurs finaux, les gestionnaires de projet et les services juridiques) et appliquées afin de déterminer les conditions de licence que le Ministère est disposé à approuver.
1. Y a-t-il des raisons qui empêcheraient la publication du code source modifié?
- * Non : sous réserve des considérations précitées, vous pouvez accepter toute licence approuvée OSI ou toute licence de logiciel gratuit de la FSF. Voir [Utiliser les logiciels libres avec modifications](#utiliser-les-logiciels-libres-avec-modifications).
+ * Non : sous réserve des considérations précitées, vous pouvez accepter toute licence approuvée OSI ou FSF.
+ Voir [Utiliser les logiciels libres avec modifications](#5-utiliser-les-logiciels-libres-avec-modifications).
* Oui : Voir 2.
2. L’application modifiée sera-t-elle utilisée comme une application Web?
- * Oui : sous réserve des considérations précitées, vous pouvez accepter toute licence approuvée OSI ou toute licence de logiciel gratuit de la FSF, à l’exception des licences à forte réciprocité. Voir [les licences à forte réciprocité](#licences-à-forte-réciprocité).
+ * Oui : sous réserve des considérations précitées, vous pouvez accepter toute licence approuvée OSI ou FSF, à l’exception des licences à forte réciprocité.
+Voir [les licences à forte réciprocité](#licences-à-forte-réciprocité).
* Non : Voir 3.
3. L’application modifiée sera-t-elle distribuée à l’externe, à l’extérieur du GC, soit le code source ou le code binaire?
- * Non : sous réserve des considérations précitées, vous pouvez accepter toute licence approuvée OSI ou toute licence de logiciel gratuit de la FSF.
- * Oui : sous réserve des considérations précitées, vous pouvez accepter toute licence approuvée OSI ou toute licence de logiciel gratuit de la FSF, à l’exception des [licences réciproques](#licences-réciproques). Utilisez seulement des [licences permissives](#licences-permissives).
+ * Non : sous réserve des considérations précitées, vous pouvez accepter toute licence approuvée OSI ou FSF.
+ * Oui : sous réserve des considérations précitées, vous pouvez accepter toute licence approuvée OSI ou FSF, à l’exception des [licences réciproques](#licences-réciproques).
+ Utilisez seulement des [licences permissives](#licences-permissives).
-Des consultations supplémentaires avec les services juridiques et les équipes de génie devraient être effectuées pour les scénarios où le logiciel libre est utilisé comme un élément d’une conception personnalisée (par exemple : lien dynamique ou statique, etc.) pour assurer la compatibilité de la licence.
+Des consultations supplémentaires avec les services juridiques et les équipes d'ingénierie devraient être effectuées pour les scénarios où le logiciel libre est utilisé comme un élément d’un développement personnalisé (par exemple : lien dynamique ou statique, etc.) pour assurer la compatibilité de la licence.
### Licences populaires et largement utilisées
-Ce qui suit constitue les listes de licences classées par catégorie permissive et réciproque. Pour voir la liste complète, consulter les sites Web d’Open Source Initiative (OSI) et de la Free Software Foundation (FSF).
+Ce qui suit constitue les listes de licences classées par catégorie permissive et réciproque.
+Pour voir la liste complète, consulter les sites Web de la Open Source Initiative (OSI) et de la Free Software Foundation (FSF).
### Licences permissives
@@ -86,24 +108,25 @@ Ce qui suit constitue les listes de licences classées par catégorie permissive
* Mozilla Public License (MPL)
* Open Software License (OSL)
-## Évaluer les options de soutien
+## 3. Évaluer les options de soutien
L’utilisation d’un logiciel libre présente un modèle différent fondé sur des services de soutien plutôt que l’obtention d’une licence de logiciel.
-Les deux principaux modèles de soutien pour les logiciels libres sont le soutien autonome, dans lequel l’équipe interne de TI du ministère ou de l’organisme est responsable de la maintenance et des interactions avec la collectivité, ou le soutien professionnel.
+Les deux principaux modèles de soutien pour les logiciels libres sont le soutien autonome, dans lequel l’équipe interne de TI du ministère ou de l’organisme est responsable de la maintenance et des interactions avec la communauté, ou le soutien professionnel.
### À l’interne
L’utilisation d’un modèle de soutien autonome exige que les équipes responsables :
* aient un processus approprié en place pour gérer l’évaluation et la mise en place des logiciels libres dans l’organisme;
-* maintiennent et fassent le suivi des listes complètes de tous les logiciels utilisés, de quelle façon et par qui;
-* S’assurent que les mises à jour soient appliquées en temps opportun.
+* maintiennent et fassent le suivi des listes complètes de tous les logiciels utilisés, de quelle façon et par qui; et
+* s’assurent que les mises à jour soient appliquées en temps opportun.
-La collectivité des utilisateurs et développeurs devrait être exploitée pour les questions de soutien général, ainsi que pour signaler les bogues, créer des demandes de fonctionnalités et des contributions de code.
+La communauté d'utilisateurs et de développeurs devrait être exploitée pour les questions de soutien général, ainsi que pour signaler les bogues, créer des demandes de fonctionnalités et des contributions de code.
-Lorsqu’on utilise des éléments de logiciel à des fins de développement, de puissants outils et services peuvent être exploités par les équipes de TI afin d’automatiser, de faciliter et d’accélérer l’identification de ces éléments, y compris les logiciels libres. Ces outils peuvent fournir des capacités d’analyse des vulnérabilités de sécurité connues ainsi que de respect des exigences juridiques.
+Lorsqu’on utilise des éléments de logiciel à des fins de développement, de puissants outils et services peuvent être exploités par les équipes de TI afin d’automatiser, de faciliter et d’accélérer l’identification de ces éléments, y compris des logiciels libres.
+Ces outils peuvent fournir des capacités d’analyse des vulnérabilités de sécurité connues ainsi que de respect des exigences juridiques.
-Voir le [Guide de contribution aux logiciels libres](#contribution-à-des-logiciels-libres.md).
+Voir le [Guide de contribution aux logiciels libres](contribution-logiciels-libres.md).
### Services professionnels
@@ -111,18 +134,19 @@ Il est possible de passer un contrat avec une entreprise de services professionn
Un autre scénario qui peut devenir récurrent serait de choisir un logiciel libre et utiliser la version communautaire, puis lancer ultérieurement un appel d’offres pour un soutien et un entretien professionnels.
-Lorsque le développement personnalisé nécessite l’utilisation de développeurs sous contrat, il faut s’assurer que les droits appropriés sur le code source soient publiés au format source ouverte, conformément au [Guide pour la publication de code source libre](publication-code-source-ouvert.md).
+Lorsque le développement personnalisé nécessite l’utilisation de développeurs sous contrat, il faut s’assurer que les droits appropriés sur le code source soient obtenus pour publier comme logiciel libre, conformément au [Guide de publication de code source libre](publication-code-source-libre.md).
-## Utiliser les logiciels libres sans modification
+## 4. Utiliser les logiciels libres sans modification
### Utiliser un logiciel libre sans modification n’exige pas que le code soit partagé
La configuration du logiciel, même par l’intermédiaire des fichiers de configuration, n’est pas considérée comme une modification.
-Cela est également vrai pour les combinaisons de logiciels libres permettant de créer une solution ou un logiciel libre utilisé pour le développement et le déploiement. Voir les exemples ci-dessous.
+Cela est également vrai pour les combinaisons de logiciels libres permettant de créer une solution ou un logiciel libre utilisé pour le développement et le déploiement.
+Voir les exemples ci-dessous.
-### Autonome
+### Seul
-Navigateur Web, suite de productivité, système d’exploitation et utilitaires (gestionnaire de Windows, environnement de bureau, éditeur de texte, console, etc.).
+Navigateur Web, suite de productivité, système d’exploitation et utilitaires (gestionnaire de fenêtre, environnement de bureau, éditeur de texte, console, etc.).
### Combinaison d’éléments
@@ -130,49 +154,54 @@ Applications et modules d’extension avec la base de données et le serveur Web
### Développement et déploiement
-Développement personnalisé à l’aide de langages de programmation de logiciels libres et dépendances, serveur HTTP, système de gestion de base de données, plateforme de conteneur.
+Développement personnalisé à l’aide de langages de programmation libres et dépendances, serveur HTTP, système de gestion de base de données, plateforme de conteneur.
### Orientation
-Pour le développement ou au moment de la rédaction du code source, consulter le [Guide pour la publication du code source libre](publication-code-source-ouvert.md).
+Pour le développement ou au moment de l'écriture du code source, consulter le [Guide de publication de code source libre](publication-code-source-libre.md).
-## Utiliser les logiciels libres avec modifications
+## 5. Utiliser les logiciels libres avec modifications
### Utiliser un logiciel libre avec modifications n’est généralement pas considéré comme une distribution et n’exige pas que le code soit partagé
-Les modifications apportées aux logiciels libres devraient quand même être partagées avec la collectivité pour aider à assurer la viabilité de la solution. Voir le [Guide de contribution aux logiciels libres](contribution-à-des-logiciels-libres.md).
+Les modifications apportées aux logiciels libres devraient quand même être partagées avec la communauté pour aider à assurer la viabilité de la solution.
+Voir le [Guide de contribution aux logiciels libres](contribution-logiciels-libres.md).
-Pour les cas où le partage des modifications est obligatoire, consulter les [répercussions à forte réciprocité](#répercussions-à-forte réciprocité).
+Pour les cas où le partage des modifications est obligatoire, consulter les [répercussions à forte réciprocité](#répercussions-de-la-forte-réciprocité).
-### Ne pas faire de fourche au logiciel libre
+### Ne pas faire d'embranchement (« fork ») du logiciel libre
### Dans la mesure du possible, utiliser des logiciels libres sans modification ou les contribuer au projet
-Utilisez la configuration et personnaliser le logiciel avec des modules, des plugiciels ou des extensions et rendre ceux-ci disponibles à la collectivité. Voir le [Guide pour la publication du code source libre](publication-code-source-ouvert.md).
+Utiliser la configuration et personnaliser le logiciel avec des modules, des plugiciels ou des extensions et rendre ceux-ci disponibles à la communauté.
+Voir le [Guide de publication de code source libre](publication-code-source-libre.md).
-Il est facile de copier (faire une fourche) un logiciel libre et de commencer à apporter des changements au code source. Si une fourche littérale est créée, ce qui signifie prendre une copie du code source et maintenir une version séparée du projet d’origine, sachez que cela rend les mises à jour et les correctifs de sécurité difficile à mettre en place. L’équipe de développement qui a fait les changements sera responsable du maintien de ces changements indéfiniment à moins qu’ils ne soient contribués à la version en amont, qui est le projet d’origine à partir duquel le code source a été pris.
+Il est facile de faire un embranchement (« fork ») d'un logiciel libre et de commencer à apporter des changements au code source.
+Si un embranchement identique est créé, ce qui signifie prendre une copie du code source et maintenir une version séparée du projet d’origine, sachez que cela peut rendre les mises à jour et les correctifs de sécurité difficile à mettre en place.
+L’équipe de développement qui a fait les changements sera responsable du maintien de ces changements indéfiniment à moins qu’ils ne soient contribués à la version en amont, qui est le projet d’origine à partir duquel le code source a été pris.
-Pour apporter des changements aux logiciels libres, collaborer avec la collectivité et présenter les changements en amont pour s’assurer qu’ils sont appuyés par les futures mises à jour. Voir le [Guide de contribution aux logiciels libres](publication-code-source-ouvert.md).
+Pour apporter des changements aux logiciels libres, collaborer avec la communauté et présenter les changements en amont pour s’assurer qu’ils sont appuyés par les futures mises à jour, voir le [Guide de contribution aux logiciels libres](contribution-logiciels-libres.md).
-**Remarque** : le terme « fourche » dans le sens littéral peut être confondu avec le processus de fourchage (clonage) des projets sur GitHub, GitLab et Bitbucket, qui est essentiel pour expérimenter et présenter des modifications au projet d’origine.
+**Remarque** : le terme « embranchement » au sens littéral peut être confondu avec le processus d'embranchement (clonage) des projets sur GitHub, GitLab et Bitbucket, qui est essentiel pour expérimenter et présenter des modifications au projet d’origine.
-### Répercussions à forte réciprocité
+### Répercussions de la forte réciprocité
-Les licences à forte réciprocité considèrent que les logiciels accessibles par l’intermédiaire d’un réseau (comme Internet) sont de la distribution et le code source modifié doit être mis à la disposition des utilisateurs. Voir les Guides sur la Publication de code source libre et sur la Contribution aux logiciels libres.
+Les licences à forte réciprocité considèrent que les logiciels accessibles par l’intermédiaire d’un réseau (comme Internet) sont de la distribution et le code source modifié doit être mis à la disposition des utilisateurs.
+Voir les Guides sur la [Publication de code source libre](publication-code-source-libre.md) et sur la [Contribution aux logiciels libres](contribution-logiciels-libres.md)...
#### Licences à forte réciprocité
-Les [licences approuvées d’Open Source Initiative](https://opensource.org/licenses/alphabetical) et les [licences de logiciels gratuits de la Free Software Foundation contiennent les licences](https://www.gnu.org/licenses/license-list.html#SoftwareLicenses) à forte réciprocité suivantes :
+Les [licences approuvées de la Open Source Initiative](https://opensource.org/licenses/alphabetical) et de la [Free Software Foundation](https://www.gnu.org/licenses/license-list.html#SoftwareLicenses) contiennent les licences à forte réciprocité suivantes :
* GNU Affero General Public License (AGPL)
* Licence publique de l’Union européenne (EUPL)
* Open Software License (OSL)
-## S’inscrire à l’Échange de ressources ouvertes
+## 6. S’inscrire à l’Échange de ressources ouvertes
-Les ministères sont encouragés à ajouter tous les logiciels libres qu’ils utilisent à la section [d’Open Source Software sur l’Échange de ressources ouvertes](https://canada-ca.github.io/ore-ero/fr/index.html).
+Les ministères sont encouragés à ajouter tous les logiciels libres qu’ils utilisent à la section [Logiciels libres de l’Échange de ressources ouvertes](https://canada-ca.github.io/ore-ero/fr/index.html).
-Le but de cette plateforme est d’aider à trouver les autres ministères qui ont utilisé avec succès les logiciels libres dans le cadre de l’environnement de production et créer des liens avec les collectivités de sources ouvertes autour d’eux.
+Le but de cette plateforme est d’aider à trouver les autres ministères qui ont utilisé avec succès les logiciels libres dans le cadre de l’environnement de production et créer des liens avec les communautés de logiciels libres autour d’eux.
Cela est également conforme à la norme numérique : Travailler ouvertement par défaut.
diff --git a/fr/normes-logiciels-libres.md b/fr/normes-logiciels-libres.md
index 118c7c1..ba262d6 100644
--- a/fr/normes-logiciels-libres.md
+++ b/fr/normes-logiciels-libres.md
@@ -1,12 +1,14 @@
# Normes Logiciels Libres
-Le gouvernement du Canada utilise les logiciels libres dans le cadre de son écosystème technologique depuis des années et compte de plus en plus sur eux pour assurer le succès de ses services. Dans le cadre de son engagement à devenir un gouvernement numérique, elle doit également contribuer à des projets externes et publier son propre code source sous licence Open Source. Elle s'engage à le faire d'une manière compatible avec les principes fondamentaux du droit administratif tels que la transparence, la responsabilité, la légalité et l'équité procédurale.
+Le gouvernement du Canada utilise les logiciels libres dans le cadre de son écosystème technologique depuis des années et compte de plus en plus sur eux pour assurer le succès de ses services.
+Dans le cadre de son engagement à devenir un gouvernement numérique, elle doit également contribuer à des projets externes et publier son propre code source sous licence Open Source.
+Elle s'engage à le faire d'une manière compatible avec les principes fondamentaux du droit administratif tels que la transparence, la responsabilité, la légalité et l'équité procédurale.
## Procedures and Guidance for Open Source Software
-- [Élaborer un cas conceptuel pour Open Source](guides/cas-conceptuel-pour-logiciels-libres.md)
-- [Acquérir des logiciels libres](guides/acquerir-logiciels-libres.md)
-- [Guide sur l'utilisation des logiciels libres](guides/utilisation-logiciels-libres.md)
-- [Guide sur la contribution à des logiciels libres](guides/contribution-à-des-logiciels-libres.md)
-- [Guide pour la publication du code source libre.](guides/publication-code-source-ouvert.md)
+- [Élaborer un cas conceptuel pour les solutions libres](guides/importance-cas-conceptuel.md)
+- [Acquérir des logiciels libres](guides/acquisition-logiciels-libres.md)
+- [Guide d'utilisation de logiciels libres](guides/utilisation-logiciels-libres.md)
+- [Guide de contribution aux logiciels libres](guides/contribution-logiciels-libres.md)
+- [Guide de publication de code source libre.](guides/publication-code-source-libre.md)
- [Définitions et termes](guides/definitions.md)
diff --git a/package-lock.json b/package-lock.json
index dd6279a..0a6d953 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -303,6 +303,88 @@
"configstore": "^4.0.0"
}
},
+ "cspell-dict-fr-fr": {
+ "version": "1.2.11",
+ "resolved": "https://registry.npmjs.org/cspell-dict-fr-fr/-/cspell-dict-fr-fr-1.2.11.tgz",
+ "integrity": "sha512-78xiS14W62QWA0GOfEcGO/VrogBcHzTlLeeiUskP29chpWyGOGrg1H/cEqAC5fg06olyRFaH7+bAfNRcLGnhww==",
+ "dev": true,
+ "requires": {
+ "configstore": "^5.0.0"
+ },
+ "dependencies": {
+ "configstore": {
+ "version": "5.0.0",
+ "resolved": "https://registry.npmjs.org/configstore/-/configstore-5.0.0.tgz",
+ "integrity": "sha512-eE/hvMs7qw7DlcB5JPRnthmrITuHMmACUJAp89v6PT6iOqzoLS7HRWhBtuHMlhNHo2AhUSA/3Dh1bKNJHcublQ==",
+ "dev": true,
+ "requires": {
+ "dot-prop": "^5.1.0",
+ "graceful-fs": "^4.1.2",
+ "make-dir": "^3.0.0",
+ "unique-string": "^2.0.0",
+ "write-file-atomic": "^3.0.0",
+ "xdg-basedir": "^4.0.0"
+ }
+ },
+ "crypto-random-string": {
+ "version": "2.0.0",
+ "resolved": "https://registry.npmjs.org/crypto-random-string/-/crypto-random-string-2.0.0.tgz",
+ "integrity": "sha512-v1plID3y9r/lPhviJ1wrXpLeyUIGAZ2SHNYTEapm7/8A9nLPoyvVp3RK/EPFqn5kEznyWgYZNsRtYYIWbuG8KA==",
+ "dev": true
+ },
+ "dot-prop": {
+ "version": "5.2.0",
+ "resolved": "https://registry.npmjs.org/dot-prop/-/dot-prop-5.2.0.tgz",
+ "integrity": "sha512-uEUyaDKoSQ1M4Oq8l45hSE26SnTxL6snNnqvK/VWx5wJhmff5z0FUVJDKDanor/6w3kzE3i7XZOk+7wC0EXr1A==",
+ "dev": true,
+ "requires": {
+ "is-obj": "^2.0.0"
+ }
+ },
+ "is-obj": {
+ "version": "2.0.0",
+ "resolved": "https://registry.npmjs.org/is-obj/-/is-obj-2.0.0.tgz",
+ "integrity": "sha512-drqDG3cbczxxEJRoOXcOjtdp1J/lyp1mNn0xaznRs8+muBhgQcrnbspox5X5fOw0HnMnbfDzvnEMEtqDEJEo8w==",
+ "dev": true
+ },
+ "make-dir": {
+ "version": "3.0.0",
+ "resolved": "https://registry.npmjs.org/make-dir/-/make-dir-3.0.0.tgz",
+ "integrity": "sha512-grNJDhb8b1Jm1qeqW5R/O63wUo4UXo2v2HMic6YT9i/HBlF93S8jkMgH7yugvY9ABDShH4VZMn8I+U8+fCNegw==",
+ "dev": true,
+ "requires": {
+ "semver": "^6.0.0"
+ }
+ },
+ "unique-string": {
+ "version": "2.0.0",
+ "resolved": "https://registry.npmjs.org/unique-string/-/unique-string-2.0.0.tgz",
+ "integrity": "sha512-uNaeirEPvpZWSgzwsPGtU2zVSTrn/8L5q/IexZmH0eH6SA73CmAA5U4GwORTxQAZs95TAXLNqeLoPPNO5gZfWg==",
+ "dev": true,
+ "requires": {
+ "crypto-random-string": "^2.0.0"
+ }
+ },
+ "write-file-atomic": {
+ "version": "3.0.1",
+ "resolved": "https://registry.npmjs.org/write-file-atomic/-/write-file-atomic-3.0.1.tgz",
+ "integrity": "sha512-JPStrIyyVJ6oCSz/691fAjFtefZ6q+fP6tm+OS4Qw6o+TGQxNp1ziY2PgS+X/m0V8OWhZiO/m4xSj+Pr4RrZvw==",
+ "dev": true,
+ "requires": {
+ "imurmurhash": "^0.1.4",
+ "is-typedarray": "^1.0.0",
+ "signal-exit": "^3.0.2",
+ "typedarray-to-buffer": "^3.1.5"
+ }
+ },
+ "xdg-basedir": {
+ "version": "4.0.0",
+ "resolved": "https://registry.npmjs.org/xdg-basedir/-/xdg-basedir-4.0.0.tgz",
+ "integrity": "sha512-PSNhEJDejZYV7h50BohL09Er9VaIefr2LMAf3OEmpCkjOi34eYyQYAXUTjEQtZJTKcF0E2UKTh+osDLsgNim9Q==",
+ "dev": true
+ }
+ }
+ },
"cspell-dict-fullstack": {
"version": "1.0.8",
"resolved": "https://registry.npmjs.org/cspell-dict-fullstack/-/cspell-dict-fullstack-1.0.8.tgz",
@@ -848,12 +930,12 @@
}
},
"markdown-link-extractor": {
- "version": "1.2.0",
- "resolved": "https://registry.npmjs.org/markdown-link-extractor/-/markdown-link-extractor-1.2.0.tgz",
- "integrity": "sha512-1unDsoZSSiF5oGFu/2y8M3E2I2YhWT/jiKGTQxa1IAmkC1OcyHo9OYNu3qCuVSj5Ty87+mFtgQxJPUfc08WirA==",
+ "version": "1.2.2",
+ "resolved": "https://registry.npmjs.org/markdown-link-extractor/-/markdown-link-extractor-1.2.2.tgz",
+ "integrity": "sha512-VYDUhlC70hKl0coCY6dXyJ4OCRAX5dTh0/oSTdidhYS7dYIJ9kYAez6KR0vc3HWySMuo564J1rN0NOAPBDI0iA==",
"dev": true,
"requires": {
- "marked": "^0.4.0"
+ "marked": "^0.7.0"
}
},
"markdownlint": {
@@ -895,9 +977,9 @@
}
},
"marked": {
- "version": "0.4.0",
- "resolved": "https://registry.npmjs.org/marked/-/marked-0.4.0.tgz",
- "integrity": "sha512-tMsdNBgOsrUophCAFQl0XPe6Zqk/uy9gnue+jIIKhykO51hxyu6uNx7zBPy0+y/WKYVZZMspV9YeXLNdKk+iYw==",
+ "version": "0.7.0",
+ "resolved": "https://registry.npmjs.org/marked/-/marked-0.7.0.tgz",
+ "integrity": "sha512-c+yYdCZJQrsRjTPhUx7VKkApw9bwDkNbHUKo1ovgcfDjb2kc8rLuRbIFyXL5WOEUwzSSKo3IXpph2K6DqB/KZg==",
"dev": true
},
"mdurl": {
@@ -1080,6 +1162,12 @@
"integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==",
"dev": true
},
+ "semver": {
+ "version": "6.3.0",
+ "resolved": "https://registry.npmjs.org/semver/-/semver-6.3.0.tgz",
+ "integrity": "sha512-b39TBaTSfV6yBrapU89p5fKekE2m/NwnDocOVruQFS1/veMgdzuPcnOM34M6CwxW8jH/lxEa5rBoDeUwu5HHTw==",
+ "dev": true
+ },
"signal-exit": {
"version": "3.0.2",
"resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-3.0.2.tgz",
@@ -1163,6 +1251,15 @@
"integrity": "sha1-WuaBd/GS1EViadEIr6k/+HQ/T2Q=",
"dev": true
},
+ "typedarray-to-buffer": {
+ "version": "3.1.5",
+ "resolved": "https://registry.npmjs.org/typedarray-to-buffer/-/typedarray-to-buffer-3.1.5.tgz",
+ "integrity": "sha512-zdu8XMNEDepKKR+XYOXAVPtWui0ly0NtohUscw+UmaHiAWT8hrV1rr//H6V+0DvJ3OQ19S979M0laLfX8rm82Q==",
+ "dev": true,
+ "requires": {
+ "is-typedarray": "^1.0.0"
+ }
+ },
"uc.micro": {
"version": "1.0.6",
"resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-1.0.6.tgz",
diff --git a/package.json b/package.json
index 5a37319..136e9d0 100644
--- a/package.json
+++ b/package.json
@@ -6,7 +6,7 @@
"scripts": {
"link-check": "node link-check.js",
"lint": "markdownlint -i node_modules \"**/*.md\"",
- "spellcheck": "cspell en/**/*.md",
+ "spellcheck": "cspell en/**/*.md fr/**/*.md",
"test": "npm run lint && npm run spellcheck && npm run link-check"
},
"repository": {
@@ -22,6 +22,7 @@
"devDependencies": {
"chalk": "^2.4.2",
"cspell": "^3.2.8",
+ "cspell-dict-fr-fr": "^1.2.11",
"glob": "^7.1.2",
"markdown-link-check": "^3.7.2",
"markdownlint-cli": "^0.18.0"