Adding French Translations

translations/fr/continuous-delivery.fr.md

@@ -0,0 +1,37 @@
+# Vérification de livraison continue
+
+> **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md))
+> 
+> Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/)
+> 
+> Sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png)
+>
+> _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ 
+
+Basé sur : 
+
+* les pratiques clés dans le livre [Continuous Delivery](http://continuousdelivery.com/) de Jez Humble et Dave Farley.
+* le livre [Continuous Delivery with Windows and .NET](http://cdwithwindows.net/) de Matthew Skelton et Chris O’Dell.
+* le résumé des pratiques de livraison continue sur [CDchecklist.info](http://cdchecklist.info/).
+
+But : *Évaluer la sensibilisation et le rendement de l’équipe à l’égard des pratiques clés de livraison continue.*
+
+Méthode : Utilisez l’approche [*Spotify Squad Health Check*](https://labs.spotify.com/2014/09/16/squad-health-check-model/) pour évaluer les réponses de l’équipe aux questions suivantes, et consignez les réponses :
+
+| **Question**                                                                                                                                                                                                                        | **Fatigué (1)**                                                                                       | **Inspiré (5)**                                                                                                                                         |
+| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1\. **Candidat au lancement** - Chaque enregistrement conduit au lancement possible (chapitre 1).                                                                                                                                                 | Nous avons des versions spéciales « Candidat au lancement » occasionnellement.                                             | N’importe quel enregistrement peut générer une version qui peut aller en Production sans une autre version.                                                                    |
+| 2\. **Effectué** - Signifie « lancé » \[c’est-à-dire, mis en production et ne causant pas de problèmes\] (Chapitre 1).                                                                                                                       | Notre définition de Terminé « Effectué » signifie que « les essais de fonctionnalité ont réussi ».                                            | Notre définition de « Effectué » signifie que les changements sont déployés à la Production avec une surveillance pour garantir que rien n’est rompu.                         |
+| 3\. **Configuration automatisée** - La configuration doit toujours être effectuée par des processus automatisés à l’aide de valeurs tirées de votre référentiel de configuration (Chapitre 2).                                                                        | Beaucoup de nos applications et essais sont configurés manuellement à chaque                                | Toutes les configurations sont effectuées à l’aide de scripts.                                                                                                                  |
+| 4\. **Options de configuration** - Il devrait être facile pour quiconque de voir les options de configuration qui sont disponibles pour une version particulière d’une application dans tous les environnements où elle sera déployée. (Chapitre 2).                      | Nous devons exécuter des différences sur divers fichiers, certains dans le contrôle de version, d’autres tirés des serveurs en direct. | Nous disposons d’une API ou d’une interface utilisateur pour afficher les options de configuration déployées dans n’importe quel environnement.                                                                              |
+| 5\. **Versions rompues** - N’enregistrez pas sur une version rompue (Chapitre 3) \[sauf pour réparer la version rompue\!\].                                                                                                                           | Nous ne pouvons pas facilement savoir quand notre équipe a rompu une version.                                              | Nous gardons la version avec soin et n’enregistrons jamais sur une version rompue.                                                                                        |
+| 6\. **Essais de non-conformité** - Ne commentez pas les essais de non-conformité (chapitre 3).                                                                                                                                                                 | Nous désactivons les essais de non-conformité pour que la version ou le pipeline fonctionne.                                    | Nous faisons confiance à nos essais; si les essais échouent, alors quelque chose ne fonctionne pas et nous allons le réparer.                                                               |
+| 7\. **Binaires** - Ne compilez vos binaires qu’une seule fois [aucune version spéciale de « candidat de lancement »] (Chapitre 5).                                                                                                                              | Nous avons plusieurs versions différentes, puis les fusionnons pour créer le candidat de lancement définitif.              | Nous n’avons qu’une seule version pour produire un artefact binaire qui est ensuite promu dans tous les environnements sans fusion ou version supplémentaire nécessaire. |
+| 8\. **Arrêt** - Si une partie du pipeline échoue, arrêtez \[tout le monde arrête le travail lié aux fonctionnalités et corrige le problème\] (Chapitre 5).                                                                                          | Le pipeline échoue si souvent qu’il est difficile de savoir quelle équipe a rompu la version.                 | Si le pipeline échoue, on connaît clairement l’équipe qui est responsable et nous arrêtons donc immédiatement notre travail pour résoudre le problème.                                 |
+| 9\. **Déploiement idempotent** - Assurez-vous que le processus de déploiement est idempotent \[nous pouvons déployer la même version plusieurs fois avec le même résultat\] (Chapitre 6).                                                                          | Il est difficile d’obtenir des déploiements répétables.                                                       | Nous pouvons redéployer la même version plusieurs fois avec le même résultat.                                                                                         |
+| 10\. **Modules de remplacement** - Utilisez des modules de remplacement pour simuler des systèmes externes \[traitez presque tous les autres systèmes comme « externes »\!\] (Chapitre 8).                                                                                                             | Il y a peu de modules de remplacement disponibles et nous n’avons pas assez de temps pour rédiger les modules de remplacement nous-mêmes.           | Les modules de remplacement que nous consommons et écrivons sont de bonne qualité et nous donnent un niveau élevé de confiance que nos essais fonctionnent bien.                                  |
+| 11\. **Réexécution de l’API** - Consignez les interactions sur un service ou une API publique (Chapitre 9).                                                                                                                                               | Nous n’avons aucun moyen de consigner les demandes ou réponses d’une API distante.                                       | Nous consignons les demandes ou réponses clés des API distantes que nous utilisons pour élaborer des essais d’intégration à haute fidélité.                                                  |
+| 12\. **Bleu vert** - Utilisez les déploiements bleu vert [à un niveau granulaire] (Chapitre 10) – c’est tout mécanisme qui vous permet de mettre à l’essai une nouvelle version à côté d’une version existante et de revenir à l’ancienne version, au besoin. | Nous n’utilisons aucune technique de déploiement bleu vert.                                                  | Nous utilisons des techniques de déploiement bleu vert à grain fin – au niveau des services individuels.                                                               |
+| 13\. **Historique de l’environnement** - l devrait être possible de voir un historique des changements apportés à chaque environnement, y compris les déploiements. (Chapitre 11).                                                                                     | Il est difficile de voir l’historique des changements dans un environnement.                                     | Nous avons un tableau de bord ou un journal des changements dans chaque environnement.                                                                                          |
+| 14\. **Modifications de base de données** - Découplez le déploiement d’applications à partir de la migration des bases de données \[et d’autres services riches en données\] (chapitre 12) – il s’agit de bases de données partagées.                                                                 | Nous devons déployer notre application ou service avec la base de données ou la couche de données.                  | Notre application ou service est complètement découplé de la base de données ou de la couche de données sous-jacente.                                                            |
+

translations/fr/deployment.fr.md

@@ -0,0 +1,23 @@
+# Vérification du déploiement
+
+> **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md))
+> 
+> Droit d’auteur © 2018-2021 [Conflux Digital Ltd](https://confluxdigital.net/)
+> 
+> Sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png)
+>
+> _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ 
+
+Basé sur les questions de maturité de Mirco Hering, auteur de [*DevOps for the Modern Enterprise*](https://notafactoryanymore.com/2018/03/01/mircos-self-assessment-questions-of-devops-maturity/)
+
+But : *Évaluer la confiance de l’équipe dans les pratiques de déploiement de ses logiciels*
+
+Méthode : Utilisez l’approche [*Spotify Squad Health Check*](https://labs.spotify.com/2014/09/16/squad-health-check-model/) pour évaluer les réponses de l’équipe aux questions suivantes :
+
+| **Question**                                                                                                                                 | **Inspiré (1)**                                                        | **Fatigué (5)**                                             |
+| -------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------ |
+| 1\. **Reconstruction d’environnement** - Que se passerait-il si nous décidions de : **vider l’environnement et le reconstruire à partir de notre configuration stockée.** | Nous ne savons pas ce qui se passerait – les environnements sont instables.         | Pas de problème – nous mettons cela à l’essai dans le pipeline de déploiement d’abord. |
+| 2\. **Nouvelle configuration** - Que se passerait-il si nous décidions de : **supprimer la configuration de l’application et la redéployer.**                                 | Nous ne savons pas ce qui se passerait – le processus de configuration est instable. | Pas de problème – nous mettons cela à l’essai dans le pipeline de déploiement d’abord. |
+| 3\. **Redéployer l’application** - Que se passerait-il si nous décidions de : **redéployer l’application même si rien n’a changé.**                      | Nous ne savons pas ce qui se passerait – les déploiements sont instables.          | Pas de problème – nous mettons cela à l’essai dans le pipeline de déploiement d’abord. |
+| 4\. **Réexécution des essais** - Que se passerait-il si nous décidions de : **réexécuter la suite des essais, et ainsi de suite.**                                            | Nous ne savons pas ce qui se passerait – la suite d’essais est vraiment instable.     | Pas de problème – nous mettons cela à l’essai dans le pipeline de |
+

translations/fr/flow.fr.md

@@ -0,0 +1,31 @@
+# Contrôle du flux
+
+> **Partie de l’évaluation de la livraison de logiciels à plusieurs équipes** ([README](README.md))
+> 
+> Droit d’auteur [Conflux Digital Ltd](https://confluxdigital.net/)
+> 
+> Sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) ![CC BY-SA 4.0](https://licensebuttons.net/l/by-sa/3.0/88x31.png)
+>
+> _Permalink: [SoftwareDeliveryAssessment.com](http://SoftwareDeliveryAssessment.com/)_ 
+
+D’après les principaux critères d’évaluation tirés des suivants:
+
+* [*Accelerate*](https://wordery.com/accelerate-nicole-forsgren-phd-9781942788331) de Nicole Forsgren, Jez Humble et Gene Kim.
+* [*Principles of Product Development Flow*](https://wordery.com/the-principles-of-product-development-flow-donald-g-reinertsen-9781935401001) de Don Reinertsen.
+* [*Team Guide to Metrics for Business Decisions*](http://bizmetricsbook.com/) de Mattia Battiston et Chris Young.
+
+But : *Évaluer la sensibilisation et le rendement de l’équipe en ce qui concerne les mesures de livraison de bout en bout.*
+
+Méthode : Utilisez l’approche [*Spotify Squad Health Check*](https://labs.spotify.com/2014/09/16/squad-health-check-model/) pour évaluer les réponses de l’équipe aux questions suivantes, et consignez les réponses :
+
+| **Question**                                                                                                                                                                    | **Fatigué (1)**                                                              | **Inspiré (5)**                                                                                                                                    |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1\. **Durée du cycle** - Combien de temps faut-il pour qu’un changement de code passe du contrôle de version à l’exécution en Production? (Minimum, standard).                                            | 2 semaines ou plus.                                                            | 1 heure ou moins.                                                                                                                                      |
+| 2\. **Fréquence de déploiement** - À quelle fréquence votre équipe se déploie-t-elle en production?                                                                                                   | Toutes les 2 semaines ou plus dans la pratique.                                        | Tous les 2 jours ou moins.                                                                                                                                |
+| 3\. **Temps moyen de résolution (TMR)** - Combien de temps faut-il pour restaurer votre application ou service après un incident?                                                                                  | Nous n’en avons aucune idée – nous ne fais pas ce suivi.                                     | Nous faisons le suivi du TMR et nous restaurons le service en 10 minutes automatiquement et nous le testons dans le pipeline de déploiement.                                              |
+| 4\. **Modifications ayant échoué** - Quelle proportion de modifications apportées à votre application ou service dans en production a échoué ou exigent une correction? (Il s’agit généralement du nombre de déploiements ayant échoué.) | Plus de 20 % de nos changements ou déploiements échouent en production.                | Moins de 5 % de nos changements ou déploiements échouent dans la production.                                                                                          |
+| 5\. **Travaux en cours** - Sur combien de choses votre équipe travaille-t-elle en même temps? (Minimum, standard.)                                                                              | Nous avons beaucoup plus d’éléments Travail en cours (TEC) que de membres d’équipe.  | Nous avons explicitement limité nos TEC en nous fondant sur la théorie des files d’attente (ou coût du retard), et le nombre de TEC est inférieur ou égal au nombre de personnes dans notre équipe. |
+| 6\. **Innovation** - Dans quelle mesure êtes-vous capable d’innover en matière d’approches de livraison?                                                                                              | Nous n’avons pas le temps d’innover.                                            | Nous consacrons du temps à l’innovation chaque semaine et suivons les progrès dans le cadre des mesures de notre équipe.                                           |
+| 7\. **Intégration** - Quelle est l’efficacité du processus d’intégration pour les nouvelles équipes et le nouveau personnel?                                                                                       | Le processus d’intégration est incroyablement difficile et freine vraiment le progrès. | Le processus d’intégration est très simple, facile et clair.                                                                                  |
+| 8\. **Âge des branches** - Combien de temps durent vos branches? (Autre que la branche maître.)                                                                                                      | Nos branches de fonctionnalités durent pour plusieurs sprints.                                 | Nous nous développons directement sur la branche maître ou le tronc et toutes les branches de fonctionnalités ne durent pas plus de deux jours.                                                               |
+| 9\. **Rétrospectives** - Quelle est l’efficacité des rétrospectives de votre équipe?                                                                                                            | Nous n’avons pas de rétrospectives périodiques.                                      | Nos rétrospectives sont vraiment énergivores/précieuses/efficaces pour l’équipe et nous les attendons avec impatience.                                                |