Le noyau
de référence.
Le site décrit une recette hors réseau sur données synthétiques. Le périmètre est le noyau : ni le service entier, ni une preuve d’efficacité sur le terrain.
Pour les systèmes d’information et les référents chargés de l’évaluationAvant de dire oui,
Avant de dire oui,
regardons à l’intérieur.
Où tournent les données ? Quels composants sont disponibles ? Qui répond de quoi ? Une première évaluation doit partir de ces questions, pas d’une promesse.
Document à partager (en italien)La fiche
La fiche
de pré-évaluation.
Périmètre, architecture logique, questions techniques et vérifications à compléter. Ce n’est pas une certification du système.
Le noyau
Le service
dans votre environnement.
Hébergement, modèles, accès, intégrations, conservation et support doivent être précisés dans la proposition effective.
Les parcours
de démonstration.
Ce site n’exécute pas de modèles et ne reçoit pas de fichiers : il transmet uniquement les demandes de premier échange. Les parcours illustrent la méthode et les restitutions.
Source pour le noyau : site COGI.CO consulté le 6 octobre 2026, qui fait état du protocole v11.1 et d’une recette du 1er octobre 2026. Aucune vérification indépendante du code n’a été menée.
Des composants distincts.
Des responsabilités explicites.
Ce schéma est une représentation éditoriale de l’architecture logique, pas une topologie de déploiement vérifiée. Il sert à distinguer ce qui doit être analysé dans la configuration proposée.
ARCHITECTURE LOGIQUE / SYNTHÈSE POUR L’ÉVALUATIONSchéma conceptuel
01
Personnes et responsabilités
Question, mandat, contrôle et choix final.
02
Méthode et conduite
Organisation de la délibération et critères de restitution.
03
Points de vue représentés
Sources, domaine, limites et conditions de contestation.
04
Noyau et mémoire de la délibération
Composition, journaux et traçabilité à documenter.
05
Modèles et services externes
Dépendances, flux de données et conditions de remplacement.
06
Environnement de l’organisation
Accès, intégrations et exploitation à définir.
Une distinction essentielle. Le fonctionnement hors réseau du noyau n’implique pas que l’interface, les modèles, les intégrations et l’exploitation du service soient tous disponibles hors réseau.
Aucune case remplie
par une simple assurance.
Chaque point demande une réponse fondée sur la configuration, un responsable et, le cas échéant, une preuve vérifiable.
DomaineCe qu’il faut vérifier
Hébergement et localisation
Où tournent l’interface, le noyau, les modèles et les journaux ? Quels fournisseurs ou sous-traitants interviennent, et dans quels environnements ?
Flux d’information
Quelles données entrent, sont traitées, éventuellement transmises à des services externes, puis restituées ? Il faut une cartographie pour chaque composant.
Modèles et dépendances
Quels modèles sont prévus ? Quelles données reçoivent-ils ? Quelles sont les conditions de remplacement, les conséquences opérationnelles et les coûts ?
Identité et autorisations
Quels accès, rôles et contrôles sont effectivement mis en œuvre ? Comment autorise-t-on l’utilisation, la modification et l’export des informations ?
Conservation et suppression
Quelles données et quels journaux sont conservés, pendant combien de temps et selon quelles procédures de suppression, d’export et de vérification ?
Intégrations et exploitation
Quels systèmes faut-il raccorder ? Avec quels prérequis, interfaces, responsabilités, maintenance et support ?
Vérification et responsabilités
Qui valide la configuration et le cas d’usage ? Quelles preuves faut-il pour l’évaluation technique et pour les autres vérifications applicables ?
État actuel de ces points : ils ne sont pas documentés sur ce site comme des capacités déjà mises en œuvre. Ils doivent être complétés avant l’approbation du projet et avant tout traitement de données dans l’environnement proposé.
Ce qu’il faut
pour bien démarrer.
Utilisez cette liste comme aide-mémoire local. Ce n’est pas une attestation de conformité ni de maturité du système ; les cases cochées ne sont ni enregistrées ni envoyées.
0 sur 6 éléments examinés · Un aide-mémoire, pas une validation
Les questions
qui comptent.
COGI est-il déjà installable dans nos systèmes ?
Ce site n’atteste pas la disponibilité d’un paquet installable complet. La configuration proposée, les composants disponibles et ceux à développer doivent être documentés par l’équipe technique dans le périmètre du pilote.
Nos données sont-elles envoyées à des modèles externes ?
Ce site n’utilise pas de modèles et n’envoie pas de données à des services externes. Pour le service réel, la réponse dépend de l’architecture retenue : il faut une cartographie des flux et des conditions documentées pour chaque fournisseur concerné.
La référence au cadre réglementaire vaut-elle conformité ?
Non. Un renvoi général ne remplace pas les évaluations portant sur le cas d’usage, la configuration, les données et les rôles effectifs. Les vérifications applicables doivent être menées par les référents compétents.
« Modèles remplaçables » signifie-t-il absence de dépendances ?
Non. C’est un choix d’architecture à traduire en conditions techniques et opérationnelles : compatibilité, continuité, coûts, délais et préservation des informations doivent être vérifiés.
La fiche PDF est-elle un document technique définitif ?
Non. C’est une fiche éditoriale de pré-évaluation, rédigée en italien, avec une matrice des informations à compléter. La version, la date et les limites figurent dans le document.
Tout part d’une question réelleUne table commune.
Une table commune.
Direction et systèmes d’information.
Le premier échange sert à délimiter ensemble la décision, les données, les conditions techniques et les critères de vérification.
Engager un échange