Just a few notes regarding:

1. Replace your @api.one with @api.multi. Beside @api.one is a deprecated decorator, it is also slower in case of multi records. In particular, if you show the field ongoing_amount in kanban or list view, your method would be launched as many times as many records are shown (usually 80) and all checks would be 80 times more frequent (e.g. the check for non-existing param). If you are sure you require only a single record, put self.ensure_one() at the beginning of your @api.multi method.

2. When you avoid using ORM, you loose some critical features including security rights. For example, in your case a simple user would see sum by all records by all companies, even though he/she doesn't have right for those. So, just take that in account.

3. I would also offer to keep 'siren' field right in account.invoice.line as a stored computed field depending on a partner siren (perhaps, also the invoice line state). Although it contradicts sql tables normalizing, it would let you avoid joining the tables which, I guess, is quite resource-consuming. Besides, in my opinion it is better to firstly search by siren and than by state, since the latter records should be represented by a bigger number.

As for the point that SQL is slower than ORM. I can't see here the real reason for that (although 'full join' leads to a few doubts). Perhaps, it is because of a used decorator, or since ORM implied SQL queries are optimized in comparison to your statements. Just as a hint: have a look at _search, search and search_count methods right in the Odoo core. Perhaps, it would lead you to some insights. Besides, if you consider migration to odoo 11 or 12: their cashing is optimized.