Manage billions lines of sensors data in mariaDB
Since you are likely to have a billion rows in this one table, I will focus on it:
CREATE TABLE `mesure` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `Machine` varchar(100) NOT NULL,
  `Date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `Valeur` decimal(18,5) NOT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `machine_timestamp` (`Machine`,`Date`) USING BTREE,
  KEY `Date` (`Date`),
  CONSTRAINT `FK_valeur_machine` FOREIGN KEY (`machine`) REFERENCES `machine` (`Name`)
) ENGINE=InnoDB;

Each row is taking about 70 bytes (including overhead); multiply that by billions of rows over 5 years, and... Get the picture?  We need to shrink this table.
decimal(18,5) -- That seems much too big.  It takes 9 bytes.  Consider using FLOAT (no, not FLOAT(18,5)).  That takes 4 bytes and has about 7 significant digits.  That is more than adequate for any sensor I know of.
Machine varchar(100) -- Shrink that down to an &quot;id&quot; that joins to the machine table.  How many machines might you eventually have?  Probably between 256 and 64K?  Use a 2-byte SMALLINT UNSIGNED both here and in the machine table.
To allow for the unlikely duplicate, do INSERT IGNORE instead of simply INSERT.
Can you get 2 readings for the same machine in the same second?  Probably not.  Or even if you did, you can (should?) throw away the redundant reading?  So, I recommend  PRIMARY KEY(machine_id, date) (and eliminate the existing UNIQUE with the same columns).
The change to the PK eliminates the 4 byte ID that you currently have.  INT is a disaster that will occur in less than a year -- when it hits the limit of about 2 billion.
Revised schema
CREATE TABLE `measure` (
  `MachineId` SMALLINT UNSIGNED NOT NULL,
  `Date` datetime NOT NULL,
  `Valeur` FLOAT NOT NULL,
  PRIMARY KEY(`Machine`,`Date`),
  KEY `Date` (`Date`),
  CONSTRAINT `FK_valeur_machine`
        FOREIGN KEY (`machineId`) REFERENCES `machine` (`ID`)
) ENGINE=InnoDB;

Those changes might cut the table's disk footprint in half.  You say the queries are fast enough now, but they will get slower over time.  This schema will help keep them &quot;fast enough&quot;.
Summary table(s)
You will probably want &quot;reports&quot; or graphs or other queries that do a big SELECT ... WHERE date between... GROUP BY machineId.  And you will find that this is slower than you like.  See http://mysql.rjweb.org/doc.php/summarytables ; we can discuss that in another Question.
Done properly, you can consider not saving the raw data for 5 years, while keeping the summarized data &quot;forever&quot;.  The summary should be one-tenth the size and 10 times as fast to query.  (YMMV - Your Mileage May Vary.)
Deleting old data
If you keep the data for only 5 years, how will you delete the &quot;old&quot; data?  You will find that a big DELETE is grossly inefficient.  Plan ahead by PARTITION BY RANGE(TO_DAYS(date)) now.  Have monthly partitions.  More:  http://mysql.rjweb.org/doc.php/partitionmaint .  DROP PARTITION is much faster.