diff --git a/features/CustomViews.feature b/features/CustomViews.feature
index d013414c58d5d9851e4b933627177608d77bfcc8..0e6c3627362b4f7e62cebe0a3be1504647e17f75 100644
--- a/features/CustomViews.feature
+++ b/features/CustomViews.feature
@@ -7,14 +7,12 @@ Feature: Custom views
     Given I am logged in a Centreon server with some widgets
 
 # public views
-  @critical
   Scenario: Share public custom view
     Given a publicly shared custom view
     When a user wishes to add a new custom view
     Then he can add the public view
     And he cannot modify the content of the shared view
 
-  @critical
   Scenario: Remove public share
     Given a publicly shared custom view
     And a user is using the public view
@@ -22,7 +20,6 @@ Feature: Custom views
     Then the view is not visible anymore
     And the user can use the public view again
 
-  @critical
   Scenario: Remove public share by owner
     Given a publicly shared custom view
     And a user is using the public view
@@ -30,14 +27,12 @@ Feature: Custom views
     Then the view is not visible anymore for the user
 
 # user shared locke views
-  @critical
   Scenario: Share read-only custom view with users
     Given a custom view shared in read only with a user
     When the user wishes to add a new custom view
     Then he can add the shared view
     And he cannot modify the content of the shared view
 
-  @critical
   Scenario: Remove read-only custom view shared with users
     Given a custom view shared in read only with a user
     And the user is using the shared view
@@ -45,14 +40,12 @@ Feature: Custom views
     Then the view is not visible anymore
     And the user can use the shared view again
 
-  @critical
   Scenario: Update a read only custom view shared with users
     Given a custom view shared in read only with a user
     And the user is using the shared view
     When the owner modifies the custom view
     Then the changes are reflected on all users displaying the custom view
 
-  @critical
   Scenario: Delete a shared custom view
     Given a custom view shared in read only with a user
     And the user is using the shared view
@@ -60,13 +53,11 @@ Feature: Custom views
     Then the view is removed for all users displaying the custom view
 
 # user shared not locke views
-  @critical
   Scenario: Modify a shared view
     Given a shared custom view
     When the user is using the shared view
     Then he can modify the content of the shared view
 
-  @critical
   Scenario: Remove an unlocked shared view
     Given a shared custom view
     And the user is using the shared view
@@ -74,7 +65,6 @@ Feature: Custom views
     Then the view is not visible anymore
     And the user can use the shared view again
 
-  @critical
   Scenario: Modify an unlocked shared view and applies changes
     Given a shared custom view
     And the user is using the shared view
@@ -82,7 +72,6 @@ Feature: Custom views
     Then the changes are reflected on all users displaying the custom view
         #Then a warning is shown to the user who wants to apply the changes
 
-  @critical
   Scenario: Deletion of an unlocked shared view
     Given a shared custom view
     And the user is using the shared view
@@ -91,14 +80,12 @@ Feature: Custom views
     And the view is removed for the owner
 
 # contact groups shared locke views
-  @critical
   Scenario: Share read-only custom view with groups
     Given a custom view shared in read only with a group
     When the user wishes to add a new custom view
     Then he can add the shared view
     And he cannot modify the content of the shared view
 
-  @critical
   Scenario: Remove read-only custom view shared with groups
     Given a custom view shared in read only with a group
     And the user is using the shared view
@@ -106,14 +93,12 @@ Feature: Custom views
     Then the view is not visible anymore
     And the user can use the shared view again
 
-  @critical
   Scenario: Update a read only custom view shared with groups
     Given a custom view shared in read only with a group
     And the user is using the shared view
     When the owner modifies the custom view
     Then the changes are reflected on all users displaying the custom view
 
-  @critical
   Scenario: Delete a shared custom view with groups
     Given a custom view shared in read only with a group
     And the user is using the shared view
@@ -121,13 +106,11 @@ Feature: Custom views
     Then the view is removed for all users displaying the custom view
 
 # contact groups shared not locke views
-  @critical
   Scenario: Modify a shared view with groups
     Given a shared custom view with a group
     When the user is using the shared view
     Then he can modify the content of the shared view
 
-  @critical
   Scenario: Remove an unlocked shared view with groups
     Given a shared custom view with a group
     And the user is using the shared view
@@ -135,7 +118,6 @@ Feature: Custom views
     Then the view is not visible anymore
     And the user can use the shared view again
 
-  @critical
   Scenario: Modify an unlocked shared view with groups and applies changes
     Given a shared custom view with a group
     And the user is using the shared view
@@ -143,7 +125,6 @@ Feature: Custom views
     Then the changes are reflected on all users displaying the custom view
         #Then a warning is shown to the user who wants to apply the changes
 
-  @critical
   Scenario: Deletion of an unlocked shared view with groups
     Given a shared custom view with a group
     And the user is using the shared view
diff --git a/features/DowntimeDST.feature b/features/DowntimeDST.feature
index 560ff1bb0f49811ec299181d32eece37e5dc374b..43676263800d772ae6d7eea3fe8ca43b20032a60 100644
--- a/features/DowntimeDST.feature
+++ b/features/DowntimeDST.feature
@@ -10,55 +10,46 @@ Feature: Downtime DST
 
 # summer changing time
 
-  @critical
   Scenario: realtime downtime starting on summer changing time
     Given a downtime starting on summer changing time
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime starting on summer changing time
     Given a downtime starting on summer changing time
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime ending on summer changing time
     Given a downtime ending on summer changing time
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime ending on summer changing time
     Given a downtime ending on summer changing time
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime starting and ending on summer changing time
     Given a downtime starting and ending on summer changing time
     When recurrent downtime is applied
     Then the downtime is not scheduled
 
-  @critical
   Scenario: realtime downtime starting and ending on summer changing time
     Given a downtime starting and ending on summer changing time
     When realtime downtime is applied
     Then the downtime is not scheduled
 
-  @critical
   Scenario: recurrent downtime during all day on summer changing date
     Given a downtime during all day on summer changing date
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime during all day on summer changing date
     Given a downtime during all day on summer changing date
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime of next day of summer changing date
     Given a downtime during all day on summer changing date is scheduled
     And a downtime of next day of summer changing date
@@ -69,64 +60,54 @@ Feature: Downtime DST
 
 # winter changing time
 
-  @critical
   Scenario: recurrent downtime starting on winter changing time
     Given a downtime starting on winter changing time
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime starting on winter changing time
     Given a downtime starting on winter changing time
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime ending on winter changing time
     Given a downtime ending on winter changing time
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime ending on winter changing time
     Given a downtime ending on winter changing time
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime starting and ending on winter changing time
     Given a downtime starting and ending on winter changing time
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime starting and ending on winter changing time
     Given a downtime starting and ending on winter changing time
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime during all day on winter changing date
     Given a downtime during all day on winter changing date
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime during all day on winter changing date
     Given a downtime during all day on winter changing date
     When realtime downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: recurrent downtime of next day of winter changing date
     Given a downtime during all day on winter changing date is scheduled
     And a downtime of next day of winter changing date
     When recurrent downtime is applied
     Then the downtime is properly scheduled
 
-  @critical
   Scenario: realtime downtime of next day of winter changing date
     Given a downtime during all day on winter changing date is scheduled
     And a downtime of next day of winter changing date
     When realtime downtime is applied
-    Then the downtime is properly scheduled
\ No newline at end of file
+    Then the downtime is properly scheduled
diff --git a/features/TestProxyConfiguration.feature b/features/TestProxyConfiguration.feature
index 6cdcd442fe422756034257613703cc9ea5e3ec5f..59eb19e3352755be0840c748b92637aa5444a364 100644
--- a/features/TestProxyConfiguration.feature
+++ b/features/TestProxyConfiguration.feature
@@ -3,14 +3,12 @@ Feature: Testing A Configuration Proxy
     I want to test my proxy configuration
     So that to verify it
 
-    @critical
     Scenario: Proxy settings with a correct connection
         Given I am logged in a Centreon server with a configured proxy
         When I test the proxy configuration in the interface
         Then a popin displays a successful connexion
 
-    @critical
     Scenario: Proxy settings with a wrong connection
         Given I am logged in a Centreon server with a wrongly configured proxy
-        When I test the proxy configuration in the interface 
+        When I test the proxy configuration in the interface
         Then a popin displays an error message
diff --git a/features/TrapsSNMPConfiguration.feature b/features/TrapsSNMPConfiguration.feature
index e9361e42b1be68c7f25edc4740b32d3c939b85b3..95901592eb275ff5f5f22b81faaeff6b97e16248 100644
--- a/features/TrapsSNMPConfiguration.feature
+++ b/features/TrapsSNMPConfiguration.feature
@@ -2,26 +2,22 @@ Feature: TrapsSNMPConfiguration
     As an IT supervisor
     I want to configure SNMP traps
     To monitore a router
-	
+
     Background:
         Given I am logged in a Centreon server
 
-    @critical
     Scenario: Creating SNMP trap with advanced matching rule
         When I add a new SNMP trap definition with an advanced matching rule
         Then the trap definition is saved with its properties, especially the content of Regexp field
 
-    @critical
     Scenario: Modify SNMP trap definition
         When I modify some properties of an existing SNMP trap definition
         Then all changes are saved
 
-    @critical
     Scenario: Duplicate SNMP trap definition
         When I have duplicated one existing SNMP trap definition
         Then all SNMP trap properties are updated
 
-    @critical
     Scenario: Delete SNMP trap definition
         When I have deleted one existing SNMP trap definition
         Then this definition disappears from the SNMP trap list
diff --git a/features/TrapsSNMPGroupConfiguration.feature b/features/TrapsSNMPGroupConfiguration.feature
index 24bc56c95d3dd9322fce56275b35d6694c99f283..327f6706c54aefe4b76640a72389d3fa7b1b17b0 100644
--- a/features/TrapsSNMPGroupConfiguration.feature
+++ b/features/TrapsSNMPGroupConfiguration.feature
@@ -7,17 +7,14 @@ Feature: Edit a trap group
         Given I am logged in a Centreon server
         And a trap group is configured
 
-    @critical
     Scenario: Change the properties of a trap group
         When I change the properties of a trap group
         Then the properties are updated
 
-    @critical
     Scenario: Duplicate one existing trap group
         When I duplicate a trap group
         Then the new object has the same properties
 
-    @critical
     Scenario: Delete one existing trap group
         When I delete a trap group
         Then the deleted object is not displayed in the list