Manuel pratique Comp’Assist · Révision : 2 octobre 2026. Exemples pédagogiques, à adapter. Les fonctions visibles dépendent de la version, des droits et des paquets installés.
Noter version, modules et extensions externes, PHP, base, répertoire des documents et méthode d’envoi des courriels. Sauvegarder base, documents et configuration ensemble. Les libellés et rubriques varient avec les modules activés ; ne pas activer tous les modules pour obtenir plus de menus.
| Rubrique | Comment remplir | Pourquoi |
|---|---|---|
| Société / Organisation | Identité légale, coordonnées, devise, pays et informations applicables | Ces données alimentent documents et calculs |
| Modules / Applications | Fonctions réellement utilisées | Chaque module ajoute des droits et parfois traitements de données |
| Affichage / traduction | Langue, formats, thème | Cohérence de lecture et documents |
| Courriels | Transport, hôte, port, TLS, compte et expéditeur autorisé | Tester réception et éviter un relais ouvert |
| Sécurité | Politique d’accès et sessions disponible | Préserver un administrateur de secours maîtrisé |
| Utilisateurs / groupes | Comptes nominaux et droits par module | Un compte externe n’a pas les mêmes usages qu’un salarié |
| Tâches planifiées si module actif | Fréquence, compte, résultat et logs | Certaines fonctions ne se déclenchent pas par une simple visite |
Pour numérotation et modèles de documents, examiner chaque module : masque, compteur, période et modèle PDF. Tester sur données fictives avant premier document réel. Les exigences comptables, fiscales et de facturation dépendent de la situation ; ne pas changer une séquence de production pour résoudre un simple problème d’affichage.
Un tiers représente une organisation ou une personne selon l’usage ; les contacts représentent les interlocuteurs. Ne créer que les champs nécessaires et éviter mots de passe ou informations sensibles dans les notes libres. Définir qui peut voir, créer, modifier, exporter et supprimer pour chaque module. Une permission d’export peut donner accès à beaucoup plus de données qu’un écran.
Tester un utilisateur limité : accès à ses modules, refus des modules non nécessaires et absence d’accès aux documents d’un autre client. Les pièces jointes doivent être protégées au niveau du serveur Web, pas seulement cachées par un bouton. Ne pas publier le répertoire des documents en accès direct.
Pour un accès réservé à l’administrateur, utiliser VPN et DNS privé avec HTTPS valide. Si des clients doivent déposer des tickets, choisir le mécanisme public/externe réellement supporté par la version et les modules. Définir les champs visibles, l’authentification, les pièces jointes, la protection antispam et les destinataires.
Le portail clients ne doit pas ouvrir l’interface d’administration ni réutiliser un compte administratif. Tester un ticket d’un client A avec un compte B et sans session : aucun accès non prévu. Vérifier que les notifications ne révèlent pas les échanges internes et que les liens de documents restent protégés.
Lire la matrice de compatibilité et la procédure officielle. Tester avec les modules externes avant production. Préparer une fenêtre sans écritures, sauvegarder l’ensemble cohérent, appliquer les migrations puis protéger à nouveau le parcours d’installation selon la version. Une migration interrompue ne se corrige pas en changeant arbitrairement des tables.
Recette : connexion, recherche de tiers fictif, génération d’un document test, upload, ticket, courriel et tâche planifiée. Vérifier logs, permissions et stockage des documents. En échec, restaurer code/base/documents cohérents et traiter les éventuelles écritures postérieures à la sauvegarde avant remise en service.