Service de Développement

Haute disponibilité

Les centres de données que nous utilisons sont certifiés Tier-III ou équivalent, avec une redondance N + 1 pour l’alimentation, le réseau et le refroidissement.
Chaque base de données client est répliquée en temps réel sur un stockage redondant situé dans le même centre de données, de sorte qu’un basculement peut se produire rapidement en cas de panne matérielle, sans perte de données.

Sauvegarde & Plan de Reprise d’Activité

Dans tous les cas, notre plan de sauvegarde et de reprise après sinistre comporte les mesures suivantes :

• 14 sauvegardes quotidiennes complètes pendant au moins 3 mois: 1 / jour pendant 7 jours, 1 / semaine pendant 4 semaines, 1 / mois pendant 3 mois.
• Sauvegardes répliquées vers un centre de données en Europe, distinct de celui de l’instance.
• RPO (Recovery Point Objective) = 24h, c’est-à-dire que vous pouvez perdre maximum 24h de travail si les données ne peuvent pas être récupérées et que nous devons restaurer la dernière sauvegarde quotidienne ;

Pour un sinistre permanent affectant un seul serveur, notre plan de reprise après sinistre comporte les mesures suivantes:

• RTO (Recovery Time Objective) = 60 minutes, c’est-à-dire que le service sera de nouveau en ligne après 60 minutes maximum (Standby promotion time + DNS propagation time).

Pour les sinistres du centre de données (un centre de données entier est complètement arrêté), le plan de reprise après sinistre comprend les mesures suivantes:

• RTO (Recovery Time Objective) = 24h, c’est-à-dire que le service sera restauré, à partir de la dernière sauvegarde, vers un centre de données différent endéans les 24 heures.

Bugs

Un bug, également appelé anomalie ou défaut, est une erreur, un dysfonctionnement ou un comportement inattendu dans un logiciel qui entraîne un résultat indésirable ou non conforme aux spécifications prévues.

Cela peut se manifester de différentes manières :

• Écart par rapport aux spécifications : Le logiciel ne respecte pas les fonctionnalités, comportements ou résultats définis dans les spécifications initiales.
• Comportement inattendu : Le logiciel agit d’une manière qui n’est ni documentée ni attendue, sans pour autant qu’une erreur spécifique soit apparente.
• Dysfonctionnement : Une fonctionnalité échoue partiellement ou complètement, rendant le logiciel inutilisable dans certaines conditions.
• Erreurs de calcul ou de traitement : Les données produites par le logiciel sont incorrectes ou incohérentes.
• Problèmes d’affichage ou d’interface : Les éléments visuels ne s’affichent pas comme prévu, nuisant à l’ergonomie ou à la compréhension des utilisateurs.
• Problèmes de performance : Le logiciel montre des lenteurs ou consomme des ressources de manière excessive, impactant la fluidité de son utilisation.

De manière générale, lorsqu’un problème affecte une fonctionnalité prévue du logiciel, qu’il est reproductible et qu’il est en contradiction avec les spécifications ou les attentes raisonnables, il est généralement considéré comme un bug.

Dans notre processus de création de logiciel, la détection et la correction des bugs font partie intégrante des phases de développement et de test, qui visent, entre autres, à identifier et corriger les éventuelles anomalies pour garantir un fonctionnement optimal du logiciel avant sa mise en production.

Il est important de noter que tous les problèmes rencontrés dans un logiciel ne sont pas nécessairement des bugs. Parfois, des différences entre les attentes de l’utilisateur et le comportement réel du logiciel peuvent être attribuées à des choix de conception délibérés, à des limitations connues, à une interprétation différente ou incomplète de certaines opérations par l’équipe de développement, ou encore à une mauvaise compréhension du fonctionnement par l’utilisateur.
Ces cas, bien qu’ils puissent sembler être des anomalies, relèvent davantage de la spécification ou de la conception initiale et sont donc généralement pris en charge dans le cadre d’améliorations, et non en tant que bugs.

En conséquence, tout problème identifié après la mise en production est d’abord évalué pour déterminer s’il constitue une véritable anomalie par rapport aux spécifications avant de procéder à sa prise en charge.
Dans tous les cas, après la mise en production, si des adaptations ou des correctifs sont nécessaires pour répondre aux attentes ou pour des ajustements non prévus initialement, les prestations en découlant feront l’objet d’une facturation distincte.

Sécurité

La sécurité de vos données est primordiale pour nous et nous concevons nos systèmes et procédures pour la garantir.
Une présentation détaillée des mécanismes mis en œuvre pour assurer la sécurité est disponible sur la page Sécurité du site Yesbabylon.com (https://yesbabylon.com/fr/cloud/security/).

En voici quelques points importants:

• SSL – Toutes les connexions Web aux instances clientes sont protégées par un cryptage SSL (HTTPS avec un certificat SSL de 2048 bits) et s’exécutent derrière des piles SSL de classe A.
• Reliable Platform – Serveurs avec garantie matérielle complète, stockage de données redondant, réseau et alimentation électrique
• Passwords – Les mots de passe des clients sont protégés par un cryptage BCRYPT/BLOWFISH standard
• Safe Systems – Nos serveurs exécutent une distribution Linux récente avec des correctifs de sécurité à jour, avec un pare-feu et des contre-mesures d’intrusion
• Isolation – Données client stockées dans des bases de données dédiées – pas de partage de données entre clients, pas d’accès possible d’une base de données à une autre