Chaintrust, comme tout outil utilisant l’intelligence artificielle, utilise une base de données pour le moins riche et vaste. C’est grâce à elle que vous pouvez automatiser votre saisie comptable de manière simple et efficace. Concrètement, comment fonctionne la base de données SQL de Chaintrust ?
Fonctionnement d’une base SQL
PostgreSQL : késako ? Chaintrust utilise une base de données PostgreSQL pour faire fonctionner ses algorithmes : vos données sont stockées dans de grandes tables (comme un immense tableur excel) pour les rendre rapidement lisibles et accessibles par des programmes informatiques. Notre code accède donc en permanence à cette table, à chaque fois que :
- vous effectuez une requête pour afficher des informations sur votre interface.
- nous traitons vos documents pour les transformer en écritures comptables.
Physiquement, ces bases de données sont stockées sur des disques durs gérés par AWS (Amazon) mais sur des serveurs basés en France. L’accès en ligne à des disques est communément appelé le cloud, bien que le seul nuage impliqué soit un nuage virtuel ! Derrière chaque cloud se cachent des serveurs physiques avec des disques durs.
Toutes les informations sont donc stockées sur des fichiers, sous forme de tableaux, avec des lignes et des colonnes simples. Chaque information (exemple : un numéro de facture) est stockée dans une cellule appelée “champ”, qui ne contient qu’une seule pièce d’information. L’ensemble des champs sur un élément est appelé “enregistrement”, “objet’ ou “ligne”. Une collection d’enregistrement est appelé “fichiers”, ou “table”.
À lire aussi : automatisation de la saisie comptable : quel intérêt ?
Comprendre la base SQL en un exemple concret
Dans notre base de données, nous avons une table appelée “companies” qui représente vos dossiers. Dans cette table, chaque “ligne” ou “objet” représente un dossier individuel que vous avez enregistré. Dans chacune de ces lignes, on enregistre les champs suivants : “nom de la société”, “numéro siren”, “date de création”, “code pays”, “email de capture”, etc.
On pourrait donc aisément représenter toute notre base de données contenant vos dossier dans un grand tableur excel, avec une ligne par société. Pour enregistrer toutes ces informations, nous utilisons une technologie open source appelée SQL (pour Structured Query Language), ou “base de données relationnelle”. Développée par IBM dès le début des années 70, cette technologie organise les données par tableau avec un champ incrémental appelé “id” : chaque nouvelle ligne contient un id qui augmente d’une unité par rapport à la ligne précédente.
C’est clair ? Non ? Continuons, dans ce cas !
Qu’est-ce que l’orienté objet ?
Les “id” ont une importance fondamentale en SQL, car ils permettent d’effectuer des jointures entre objets. La raison pour laquelle ces bases de données sont appelées “relationnelles” est que les tables entrent en relation les unes avec les autres via des foreign key. Rentrons un peu dans le détail.
Lorsque nous reconstituons les pages d’un de vos dépôts, nous créons dans notre base de données un objet appelé “Document”. En code, un “objet” est une instance particulière d’une classe, dont il hérite des comportement et des caractéristiques. C’est un objet indépendant qui représente quelque chose de physique dans le monde réel. Dans notre exemple, l’objet appelé “Document” représente une facture ou un document comptable, de même que la “Company” représente l’un de vos dossiers. Chacun de ces deux objets est représenté par sa propre table dans notre base de données.
De la même manière, vos cabinets comptables sont représentés par une table dans notre base de données appelée “Fiduciaries”. Cette table contient les informations propres à votre cabinet, comme l’adresse, le numéro de téléphone, etc.
Ces objets interagissent ensemble via une clé étrangère. On enregistre donc dans chacun de nos documents un champ appelé “company_id”, et dans chaque “company” un champ “fiduciary_id”. Cela nous permet facilement d’effectuer des “requêtes” dans notre base de données pour savoir quels documents concernent quels dossiers, et par extension, quelle fiduciaire.
Call serveur S3 : et la boucle est bouclée
Enfin, chacun de ces objets, lorsqu’il est représenté par une image physique (comme l’objet “Document”, représentant une facture), possède un champ “file_name”, qui les lie à un lien spécifique sur des bandes de stockage S3. Ces bandes de stockages sont chargées de stocker vos images indépendamment de la base de données, afin de garder nos bases les plus légères possible. En effet, chacune de vos factures peut peser plusieurs mega-octets.
Ainsi, traiter des centaines de milliers de factures chaque mois comme nous le faisons rendrait la base absolument gigantesque, et ingérable rapidement : la rapidité des requêtes dépend en effet fortement de la taille de la base de données.
Voilà en bref le fonctionnement de Chaintrust : lorsque vous effectuez une requête pour afficher un document, le code relaie votre requête dans la base de données, qui renvoie un nom de fichier, permettant au code d’aller chercher dans les bandes de stockage S3 l’image que vous recherchez. C’est plus clair ? On discute, si besoin !
