diff --git a/commands.md b/answers.md
similarity index 73%
rename from commands.md
rename to answers.md
index aa50587..a0e2730 100644
--- a/commands.md
+++ b/answers.md
@@ -53,4 +53,16 @@ _Explain in a few lines and compare it against your first solution._
 
 5. Now that everything is running as expected, it is time to suggest a production rollout for this service. Please suggest changes to the service to ensure a secure, production-ready deployment to be accessed by a team of developers. The suggestions are not limited in scope, but should focus on security, performance and reliability.
 
-_Explain in a few lines._
\ No newline at end of file
+ - L'accès à jenkins se fait à travers d'un mot de passe propre à chaque utilisateur (SSO si disponible pour simplifier l'user experience) et avoir une 2FA. Une politique de moindre privilège peut etre mis en place, des plugins comme : https://plugins.jenkins.io/role-strategy/ permettent de faire ce genre d'action.
+
+ - Avoir au moins deux masters avec un Haproxy devant pour que si un master tombe l'autre prend le relais. Pour éviter le SPOF sur le haproxy on peut en mettre deux avec keepalived pour qu'on puisse accéder aux master à travers une VIP.
+
+ - Dans un soucis de scalabilité et de sécurité l'architecture de build distribué est à priviligié. C'est à dire que les builds sont effectué par des agents au lieu du master, ce qui permet de protéger le master du code déployé ou d'une mauvais manipulation d'un developpeurs. Pour la partie scalabilité, si on a besoin de plus de ressources pour gérer plus de build on peut donc ajouter plus d'agents.
+
+ - Un plugin comme https://plugins.jenkins.io/job-restrictions/ permet de faire en sorte que des jobs s'execute que sur certains agents. Ce qui peut permettre de séparer les jobs et les agents en fonction des équipes. Chaque équipe à ses propres ressources.
+
+ - Backup
+
+ - Centralisation des logs
+
+ - kubernetes
\ No newline at end of file