Tableau comparatif des besoins de SugarCRM spécifiés par Solution Métrix et des spécifications techniques réclamées par l'AuF.

''Note : ce tableau est basé sur la partie « 6. Spécifications techniques » de la réponse à l'appel d'offres lancé par l'AuF.''

|| ||'''Besoins SugarCRM'''||'''Cadre technique AuF'''||'''Statut'''||
||'''Mémoire''' || ≥ 4 Gio || 4 Gio || (./) ||
||'''Système d'exploitation''' || Linux/Unix/MacOS, IBMi, Windows || Debian GNU/Linux 8 “Jessie” || (./) ||
||'''MySQL''' || 5.1, 5.5 || 5.5.44 || (./) ||
||'''Apache''' || 2.0, 2.2 || 2.4.10 || (./) ??? {X} ||
||'''PHP''' || 5.2, 5.3 || 5.6.13 || (./) ??? {X} ||
||'''elasticsearch''' || ≥ 0.19.3 || 1.0.3, 1.6.2 ''(backports)'' || (./) ??? {X} ||

- Espace disque?

Points à vérifier :
 * quelle est la deadline pour démarrer (= mise en place d'une première plate-forme) ?
 * utilisera-t-on SugarCRM natif ou une version dérivée ?  dans ce dernier cas par qui est-elle maintenue ? | la version dérivée qui est prévue par Metrix pour ce projet est https://suitecrm.com/|
 * est-il nécessaires d'installer (et maintenir) des modules PHP non standards ?
 * comment se passent les mises à jour de sécurité ? (transparentes ? à chaud ?)
  . la question se pose selon 2 angles : la partie système (qui comprend Apache + PHP + elasticsearch) et la partie application (qui ne concerne que SugarCRM)
  . qui fait quelle partie ?
 * comment se passent les mises à niveau de l'application SugarCRM ?
  . qui fait quelle partie ?
 * y a-t-il une procédure de recette automatique (batterie de tests automatisée) des fonctionnalités de SugarCRM ? (à lancer à la demande après une modification niveau système ou application)
 * est-il possible de créer séparément des comptes d'administrateurs techniques (pour les sysadmins) et des comptes d'administrateurs fonctionnels (pour les métiers) ?
 * est-il possible de gérer plusieurs environnements dans un seul moteur SugarCRM ?
  . sinon, de combien d'environnements a-t-on besoin et qui les gère/maintient techniquement ?
## si c'est 100% AUF, est-ce la partie IT ou SI qui en prend la charge ?
      . envisagé oralement:
      .. DEV - chez SM
      .. TEST(interne) - test unitaires sur données non a jour
      .. FORM(interne) - formation et training
      .. PREPROD(interne) - validation sur données réelles  
      .. PROD(interne) - (voir si FORM sur meme machine)
      -. intégration SAML
 * versioning avec github
 * liste de diffusion sécurité SuiteCRM


Clarification en interne:
 * Mailman (bien anticiper l'isolation envoi de courriels)
 * sizing (voir début de page)
 * si MAJ majeure de sécurité, on monte un env en interne depuis la PROD scratchable(donc temporaire). validation par SI.
 * certificats SSL