État public de chaque capacité
Chaque intégration est classée selon un résultat observable. « Disponible » signifie qu’un parcours interne peut être rejoué et que sa sortie peut être ouverte. « Documenté » signifie que le format ou le scénario est décrit, sans prouver qu’un tiers l’accepte aujourd’hui. « Non ouvert » signifie qu’aucun contrat d’API générale n’est proposé aux clients. Cette grille évite de transformer une route interne, une maquette, un export ou un partenariat en connexion de production. Elle doit être relue à chaque évolution du service.
| Capacité | État public | Preuve attendue |
|---|---|---|
| Import CSV encadré | Disponible selon le parcours | Échantillon, rapport et rapprochement |
| Exports et packs JSON/CSV | Disponibles | Fichiers téléchargés et ouverts |
| Flux catalogue nommés | Documentés | Réception à tester avec chaque destination |
| Raccordement à la Plateforme Agréée partenaire | Ouvert dans chaque compte | Activé par chaque entreprise : autorisation, vérification, premiers flux |
| API générale d’écriture | Non ouverte | Aucun contrat public annoncé |
Importer un CSV avec contrôle avant bascule
Livre de Police dispose d’un parcours d’import CSV encadré. Un fichier n’est jamais fiable parce qu’il vient d’un logiciel connu : les colonnes, dates, montants, catégories, références et doublons doivent être cartographiés. Commencez par une copie de la source et un petit échantillon comprenant des cas simples, incomplets et atypiques. Examinez le rapport, corrigez les lignes rejetées puis comparez les objets créés avec le fichier d’origine. Une importation réussie techniquement ne crée pas rétroactivement la continuité juridique d’un ancien registre et ne justifie pas la suppression immédiate de la source.
- Fichier source conservé
- Colonnes cartographiées
- Échantillon avant le lot
- Rapport et rapprochement final
Exporter pour reprendre le contrôle des données
Les exports servent à vérifier, transmettre ou migrer. Selon le parcours, Livre de Police prépare des fichiers PDF, CSV, JSON, structurés ou associés à la facturation. Le nom du format ne garantit ni l’exhaustivité, ni l’acceptation par le destinataire. Téléchargez le fichier, ouvrez-le hors du service, vérifiez l’encodage, les colonnes, les périodes, les montants et les objets attendus. Pour une migration, conservez aussi le schéma et la date d’export. Pour un cabinet ou un outil tiers, demandez un import test et un compte rendu avant d’automatiser la transmission.
- Fichier ouvert hors Livre de Police
- Période et périmètre contrôlés
- Schéma conservé
- Acceptation tierce vérifiée séparément
Douze packs ne signifient pas douze API connectées
Le moteur de multidiffusion prépare douze variantes adaptées aux destinations nommées et permet de les exporter en JSON ou CSV. Une démonstration publique exécute ce constructeur sur une commode fictive et publie les sorties, leurs scores et leur empreinte. Chaque pack indique explicitement que la connexion et la publication n’ont pas eu lieu. Ce fonctionnement est utile : il évite la ressaisie et permet une validation canal par canal. Il ne prouve ni l’authentification auprès des plateformes, ni l’acceptation d’une annonce, ni son URL, ni son retrait après la vente.
- Douze variantes réellement construites
- Données privées exclues
- Validation humaine
- Publication externe à prouver canal par canal
Cinq flux catalogue documentés, à recetter côté destination
Certaines destinations peuvent consommer un flux de catalogue plutôt qu’une API transactionnelle. Livre de Police documente cinq flux distincts dans son périmètre actuel. La présence d’une URL ou d’un fichier conforme au schéma interne ne prouve pas que la plateforme distante l’a récupéré, indexé ou accepté. Pour chaque destination, créez un compte autorisé, transmettez un catalogue fictif ou de recette, contrôlez le retour, l’objet visible, l’actualisation du stock et le retrait. Conservez la version du format et la réponse externe. Sans ce retour, la bonne formulation reste « flux préparé ou documenté ».
- Destination et droit identifiés
- Format et version connus
- Réponse distante conservée
- Mise à jour et retrait contrôlés
Des preuves JSON publiques, pas une API client générale
Les démonstrations IA et multidiffusion exposent des fichiers JSON publics afin que le visiteur puisse inspecter un exemple fictif, les limites et les empreintes. Ces URL sont volontairement en lecture seule et ne contiennent ni client, ni vendeur, ni écriture réelle. Elles ne constituent pas un contrat permettant à un logiciel externe de créer, modifier ou supprimer le registre. Cette distinction protège le service et les données : un endpoint de preuve sert à vérifier une sortie ; une API client nécessite une version, une authentification, des autorisations, des quotas, une documentation et un support stables.
- Exemples fictifs
- Lecture seule
- Aucune donnée client
- Aucun contrat d’écriture implicite
Facturation électronique : le raccordement est ouvert, l’activation reste la vôtre
Livre de Police reste un logiciel de gestion relié à une Plateforme Agréée ; il n’est pas lui-même une Plateforme Agréée. Le portail de production est ouvert et l’accès figure dans chaque compte. Aucune entreprise n’est inscrite automatiquement : la preuve complète pour un client commence lorsqu’il termine sa propre autorisation, sa vérification et ses premiers flux réels.
- Livre de Police distinct de la Plateforme Agréée
- Accès dans chaque compte
- Activation par l’entreprise elle-même
- Aucune inscription automatique
Les routes internes ne sont pas un engagement commercial
Une application web utilise naturellement des endpoints pour ses propres écrans, son mobile, sa boutique ou ses tâches d’administration. Découvrir une route dans le code ne signifie pas qu’elle est stable, documentée ou autorisée pour un client externe. Les routes internes peuvent changer avec l’interface et suivre des permissions conçues pour la session utilisateur. Livre de Police ne recommande donc pas de construire une intégration sur une URL observée dans le navigateur. Toute intégration durable doit disposer d’un périmètre écrit, d’une version, d’identifiants dédiés, d’une politique d’erreur et d’un scénario de révocation.
- Contrat écrit
- Version stable
- Identifiants dédiés
- Révocation et erreurs documentées
Conditions minimales avant d’ouvrir une API d’écriture
Écrire dans un registre engage davantage qu’importer un catalogue. Une future API devrait limiter chaque jeton à une organisation et un établissement, séparer brouillon et validation, appliquer l’idempotence, contrôler les volumes, journaliser l’auteur, refuser les corrections destructives et rendre les erreurs explicites. Elle devrait aussi protéger les données d’identité, éviter leur exposition dans les journaux et prévoir la rotation des secrets. Avant ouverture, les scénarios d’accès croisé, de rejeu, de révocation et d’indisponibilité doivent être testés. Publier cette liste est plus utile qu’un bouton « API » sans contrat ni garanties.
- Périmètre organisation et établissement
- Brouillon séparé de la validation
- Idempotence et journalisation
- Tests d’isolation et de révocation
Demander une intégration avec un dossier mesurable
Si votre entreprise a un besoin qui dépasse le CSV et les exports, décrivez le système source, le sens de l’échange, le volume, la fréquence, les champs, les données personnelles, les établissements, le résultat attendu et la procédure d’erreur. Fournissez un exemple fictif et définissez une recette. Livre de Police peut alors confirmer ce qui existe, proposer un échange de fichiers ou étudier un contrat spécifique. Aucun développement ni prix ne doit être déduit de cette page. La décision dépend de la sécurité, de la maintenance, du nombre d’utilisateurs concernés et de la valeur réelle par rapport à une intégration plus simple.
- Système source et destination
- Volume et fréquence
- Données et droits
- Scénario de recette et retour arrière