Comprendre le processus
Identifier les utilisateurs, le problème à résoudre, le marché visé et les scénarios qui ne peuvent pas échouer.
Méthode
Rendre le travail prévisible sans promettre une durée uniforme.
La méthode part du processus, des données et des responsabilités. Elle conduit jusqu’aux tests d’exploitation, à la documentation et à la reprise.
Cette page décrit comment ATMYS produit. Le déroulé de chaque offre — sprint, développement, suivi — est détaillé sur les pages Automatisation et Logiciel sur mesure.
Huit étapes
Le système est compris avant d’être figé.
Les étapes se chevauchent lorsque le produit l’exige, mais aucune ne disparaît derrière une promesse de vitesse.
Cartographier le système
Décrire les données, les acteurs, les flux, les dépendances et les environnements avant de choisir l’architecture.
Qualifier les contraintes
Séparer les réponses techniques des validations qui appartiennent au client, au DPO, au RSSI ou à un spécialiste.
Décider et consigner
Comparer les options, expliciter les compromis et conserver la raison des décisions structurantes.
Construire par incréments
Mettre régulièrement une version utilisable entre les mains des personnes qui connaissent le métier.
Tester l’exploitation
Vérifier les accès, les erreurs, la journalisation, les sauvegardes et les scénarios de reprise proportionnés au risque.
Documenter les preuves
Assembler le périmètre, les flux, les dépendances, les mesures, les limites et les décisions dans un dossier exploitable.
Préparer la reprise
Transmettre le code, les comptes convenus, les procédures et le plan de sortie sans rendre le client dépendant d’ATMYS.
Responsabilités
Qui produit, qui décide, qui est consulté, qui valide.
La matrice est adaptée au projet. Elle évite de confondre la mise en œuvre technique avec une validation juridique, réglementaire ou indépendante.
| Étape | ATMYS produit | Le client décide | Personnes consultées | Validation |
|---|---|---|---|---|
| Cadrage | Scénarios, flux, options et questions ouvertes | Finalités, priorités métier et risques acceptables | Utilisateurs, DPO, RSSI, achats selon le contexte | Responsable produit côté client |
| Architecture | Comparaison des options et décisions techniques | Budget, fournisseurs et compromis structurants | DSI, hébergeur, spécialistes concernés | Client et responsable technique ATMYS |
| Construction | Logiciel, tests, déploiement et documentation | Règles métier, retours et ordre de priorité | Utilisateurs et équipes d’exploitation | Responsable produit côté client |
| Revue et reprise | Dossier technique, procédures et réponses factuelles | Décisions finales et plan d’action | DPO, RSSI, auditeur ou conseil indépendant | Chaque validateur dans son périmètre |
Décisions
Une contrainte utile modifie le produit.
Une cartographie de données qui ne change aucun choix, une revue de dépendances sans plan d’action ou un questionnaire sécurité rempli sans preuve ajoutent peu de valeur.
ATMYS relie chaque contrainte retenue à une décision : minimiser une donnée, séparer un rôle, journaliser une action, tester une restauration, documenter un fournisseur ou prévoir un export.
Parlons du périmètre
Présentez le contexte avant de choisir l’architecture.
Quelques éléments suffisent pour commencer : utilisateurs, processus, données, systèmes à intégrer et contraintes déjà connues.